Code::Blocks' translation

[gd_on]

OK. So it's an other problem.
I tried different things as :

• using directly the .mo file downloaded from launchpad;
• download the .po from launchpad, compiling it with poedit, and using the .mo produced (with and without renaming it)
• using my own .mo file ...

everything work as expected.

I also tried to rename a .mo file in .po, just to see what happens. C::B logically appears in English : no assert message.

So, I can't reproduce your behaviour.

One idea : Are you sure you use a wxWidgets version compiled with the same compiler version as your Code::Blocks build ?

There is also an other thing which look strange for me :
at line 405 in menucmn.cpp (located in C:\wxWidgets-3.1.5\src\common for me), I have :

Code

wxMenuItemList::compatibility_iterator node = m_items.Item(pos);

which does not correspond exactly to your indicated code lines. For me it's inside wxMenuBase::DoInsert (not in wxMenuBase::Insert)
Assert lines are 403 or 406. So, may be we have not exactly the same wxWidgets 3.1.5 version !)

Note : it's in wxWidgets 3.1.6 (trunk version, beta) that I have a wxcheck at line 405, inside wxMenuBase::Insert ! But, I still don't use it in C::B.

[LETARTARE]

Thanks, your test is valuable.
I had downloaded 'wx-315' sources on the 'WXWidgets' website and had compiled using 'gcc-810' without problem until this test.

I will check everything today...

[gd_on]

Also tested with last killerbot version (today's one), of course with all his given dlls (compiler and wxwidgets). It works as expected.

[LETARTARE]

Thanks for your tests.

In doubt I recompiled 'wx-315' and the size of the result was different from the old one, even though I used the same source and the same compiler and the same build script ??
With this recompiled version, no more problem with your translation files compiled by 'Poedit'.

Thanks for the translations.

[rechtsanwaltsteyer]

If somebody needs translation files to German language, feel free to follow this link an download the needed files:
https://www.dropbox.com/sh/bjuy411x4vv7ehm/AABgOFckrY5MklvvdLSLIAmHa?dl=0 

[gd_on]

A new updated version of my translatable string extracting tool can be found here.
It is able to scan new translatable strings in plugin scripts.
The english template on Launchpad has also been updated (https://launchpad.net/codeblocks-gd) [appoved but not still imported in the data base]
However, for translators, many of the new strings are only partial sentences. As the word order in the recomposed full sentences may depend on the language, it is advisable not to translate them and to wait for a future rework on them.

[Miguel Gimenez]

Main plugin's manifest.xml contents appear in the POT, but not those from the contrib folder.

For example, the debuggergdb plugin's contents are in the POT, but those in regex_testbed from contrib are not.

With [r13017] you can see the difference, for example, in the Help -> Plugins menu.

In you bash file, the line

Code

find ../plugins | grep -F manifest | grep -F .xml | grep -v svn-base | grep -v .svn | xargs sed -n -e '/description/,/>/p' | sed '/author/d' | sed ':a;N;$!ba;s/\n/\\n/g' | sed 's/""//g' | sed 's/>\\n/>'"\\${nl}"'/g' | sed 's/"/\\"/g' | sed 's/&/\&/g' >  src_xml3.cpp 2>> log.txt

should be modified to do a recursive search (or add another line for plugins/contrib).

EDIT: why don't you use

Code

find ../plugins -name manifest.xml

instead of

Code

find ../plugins | grep -F manifest | grep -F .xml

[gd_on]

EDIT: why don't you use

Code

find ../plugins -name manifest.xml

instead of

Code

find ../plugins | grep -F manifest | grep -F .xml

because there are a few manifest in Smartindent as manifest_cpp.xml, manifest_fortran.xml,... which are missed with only manifest.xml

Decoding an xml file is not so simple than a cpp or a .h file. I first extract lines containing some specific strings as description, author, ... to create a pseudo cpp file, here src_xml3.cpp. It needs some adjustments : that the reason of all the intermediate sed modifications. Then this pseudo cpp is concatenated and analyzed. Doing like that, the real origin of the string is lost, but normally it should be there. find itself do a recursive analysis.
Nevertheless, it's possible that I have missed something, a specific field, maybe the line containing "title" ?
In the regex_testbed manifest, the description "A testbed for regular expressions." is in the .pot file, and is translated in my po file. This proves that find does the recursive job...

[Miguel Gimenez]

The title Regular expressions testbed does not appear, for example.

[gd_on]

So, you mean that I should detect the "title" line in the manifest.xml? (or the "name" line? or both?)

[Miguel Gimenez]

I think title, description, thanksto, license, name and version should need translation.I added _() to them in [r13015] and [r13016].

Title and description are a must.
Thanksto may be needed if it contains something like "My mother".
License may contain "Modified wcWidgets license"
Name is not too interesting, but may be needed.
Version will usually be numbers/dots, but it could contain other strings.

Curiously enough, title for CodeCompletion, DebuggerGDB and others appear in the POT, while others do not.

[gd_on]

I think title, description, thanksto, license, name and version should need translation.I added _() to them in [r13015] and [r13016].

Title and description are a must.

Done

Thanksto may be needed if it contains something like "My mother".

Done

License may contain "Modified wcWidgets license"

Done, but as it is the last field, it works only if the text is on 1 line (it's always the case)

Name is not too interesting, but may be needed.

Not done.

Version will usually be numbers/dots, but it could contain other strings.

Not done

Curiously enough, title for CodeCompletion, DebuggerGDB and others appear in the POT, while others do not.

This is because the strings are also found in other files (as .cpp for example).

I also tried author but it's not easy:

• One manifest (wxSmithAUI) contains characters with accents in the author name. xgettext does not like them. A workaround is to replace these characters with ascii one (no accents)
• it is difficult to separate athor, authorMail and authorWeb fields. If the 1srt one may need a translation (in some cases where there is a co-author plus a small translatable text), others do not need translation
• some names appear several times in the .pot file, just becase they are not stricly the same: a space, a !, a capital letter... Note that it is also the case for some other strings in other fields

You'll find attached a modified version of the batch file and the .pot generated. Need still some work...

gd_on

[Miguel Gimenez]

Thank you.

"Not done" means "won't do"?. If yes, I will remove the _() from those fields in dlgaboutplugin.cpp.

Author usually does not need translation, unless it is something like "The wxWidgets team". I will remove accents from wxSmithAUI.
Author's mail and web will not need translation.

some names appear several times in the .pot file, just becase they are not stricly the same: a space, a !, a capital letter... Note that it is also the case for some other strings in other fields

This is a nightmare, but little can be done now. Another problem are wxSmith-generated strings, they always use _() even for numbers.

New code should be more translator-friendly, but currently it is not.

[gd_on]

"Not done" means "won't do"?. If yes, I will remove the _() from those fields in dlgaboutplugin.cpp.

I think I can add but I think it's not needed. No real benefit.

[gd_on]

A updated version of my translatable string extracting tool can be found here.
It is able to scan new translatable strings in manifest.
The english template on Launchpad has not been still updated (https://launchpad.net/codeblocks-gd).
My previous update was approved but not still imported in the data base. I cannot update more, I cannot also download a translation file: the download request is accepted but I don't receive the mail to download it. Is there a problem on launchpad ?