Code::Blocks Forums
Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: thomas on June 29, 2007, 06:20:42 pm
-
Seeing that we're not doing a feature freeze, I've cleaned up some code that's been annoying me for a long time. :)
Internationalisation support now:
- only opens 5 wrong locations instead of 20 for every catalog opened (unluckily, wxWidgets is too f...ing braindead so you can't get it on the first attempt, but 5 is better than 20)
- no longer stores an integer, but an ISO language string in the config file
- no longer clutters up the config file with catalogs that don't exist any more
- no longer tries to load catalogs that don't exist any more (looking in 20 locations for each)
- no longer hardcodes languages and no longer requires you to rebuild the application to add support for a language
- actually works
What's different for core developers:
Basically, nothing.
What's different for translation maintainers:
1. Everything that belongs to the core application should go into codeblocks.po/mo and everything that belongs to the core plugins should go into core-plugins.po/mo for the sake of efficiency (only load 2 files).
2. Everything that belongs to contrib plugins goes into pluginname.po/mo (but is not your problem, anyway).
What's different for plugin developers:
If you want to localise your plugin, create a yourplugin.po file and the respective yourplugin.mo files.
Drop the .mo files into $SHARE/codeblocks/locale/lang_CODE and Code::Blocks will use them.
-
Is there any way to use https://translations.launchpad.net/codeblocks/ (https://translations.launchpad.net/codeblocks/)? Few languages are ready to go :)
BYO
-
Is there any way to use https://translations.launchpad.net/codeblocks/ (https://translations.launchpad.net/codeblocks/)? Few languages are ready to go :)
Well... yes...?! I mean - this page is to create *.po and *.mo files which work after applying Thomas' changes. You can d/l the *.po/*.mo files from launchpad. Or what do you mean?!
With regards, Morten.
-
Is there any way to use https://translations.launchpad.net/codeblocks/ (https://translations.launchpad.net/codeblocks/)? Few languages are ready to go :)
BYO
Download the codeblocks.mo file there, and copy it to the right place, that's it. Downloading is a bit awkaward, you first need a launchpad account, then you request the download, and you are sent an email containing the download link. Don't ask why it's so complicated :)
For a Polish translation, the file would have to go to $SHARE/codeblocks/locale/pl/codeblocks.mo. Any valid lang or lang_COUNTRY code recognized by wxWidgets will be ok.
What Code::Blocks does is this:
1. At startup, it loads the language code from the config and sets the locale accordingly. If something fails, it uses "system default". Then it gets the canonical name for whatever was chosen and lists the .mo files inside the respective directory, adding each of them to the catalog list.
2. When configuring localisation, Code::Blocks lists all directories inside the locale folder, and then verifies one by one if it is a valid ISO code. If it is, it replaces the code with its corresponding human-readable string, adding that to the menu.
Thus, there is no need to hardcode anything any more, and adding a language (or a localisation for a plugin) is a matter of dropping a file into a folder.
If we are to adhere to the standard pedantically, putting the files into $SHARE/codeblocks/locale/lang_COUNTRY/ is wrong, it should be $SHARE/codeblocks/locale/lang_COUNTRY/LC_MESSAGES/.
However, wxWidgets looks in both places anyway, and leaving out the LC_MESSAGES bit removes one unnecessary level of indirection. There is never anything but this one folder inside the language folders, which is kind of pointless, really. Also, it confuses users who haven't done this before (it took me a while to figure out, too).
Code::Blocks will therefore load all files matching *.mo in the lang_COUNTRY folder, which is easier, more comprehensible, and works fine.
-
Oh, on a different note... the old i18n code left a lot of data (one entry for every plugin that you once used) in the config. You can remove all this payload, if you wish, to slim down your config a bit.
The locale config now looks like this (for German (de) language):
<locale>
<ENABLE bool="1" />
<LANGUAGE>
<str>
<![CDATA[de]]>
</str>
</LANGUAGE>
</locale>
The <I18N> tag under environment, and anything related to catalog number or domains inside <locale> can be safely deleted, saving around 1.5 kB of config file space.
You can leave it in place, too... it won't do any damage, other than take a little space.
-
Download the codeblocks.mo file there, and copy it to the right place, that's it.
Sounds really nice :) I just thought that if it's already decided to split translation itno smaller files, one big file won't be as "valuable" as few smaller.
Anyway, I'll try to test the IDE in my language, let's see how it works :D
Thanks for help
BYO
EDIT: Ok, there's something wrong with Launchpad, when I select mo file it downloads po instead :?
-
EDIT: Ok, there's something wrong with Launchpad, when I select mo file it downloads po instead :?
Same problem, here.
-
EDIT: Ok, there's something wrong with Launchpad, when I select mo file it downloads po instead :?
Same problem, here.
The easiest way is to install poEdit, download po file, open in poEdit save and voila, there's .mo file :)
I've already managed to see polish translation but it's only 40% complete so it's actually mixed-language IDE ;)
BYO
-
Wow, german codeblocks.
Very nice :D
-
What's funny is that now my Code::Blocks became a Spanglish version. I don't really know if moving to wxGTK 2.8.4 had something to do with it, but it's also the first time I try it with the current internationalisation update. For example, the first and last items of the menu are in Spanish, all others in English, and I haven't installed any translation files.
And there's also another minor problem: the default installation does not create locale in /usr/local/share/codeblocks, so every single time I run Code::Blocks it complains because it's unable to enumerate the contents of that directory. Creating it solves the problem, but it should be evaluating the existence of that directory first, or be sure make install will create it.
-
I just thought that if it's already decided to split translation itno smaller files, one big file won't be as "valuable" as few smaller.
Ah ok, I was not aware of any decisions/discussions on that topic.
Putting everything "application" into one file, and everything "core plugins" into a second one, and for every additional plugin one file was my idea because adding a catalogue is an immensely expensive operation.
wxWidgets executes about 1000 lines of code to mangle file names, copies and shift strings around, then looks in a couple of directories, loads and parses a file, and executes another 1000 lines of code -- for every catalogue you add.
Therefore, putting things that somehow belong together into one file seemed like a good idea to me. But sure, it's no difference if we have 20 files instead, Code::Blocks will load anything that matches *.mo, will only take a few more cycles for the same effect :)
That reminds me that wxWidgets has some obscure localisation of its own in a localised file called wxstd.mo. I don't know what those files contain, but the application secretly tries to load such a file at startup. Funnily, there only seem to exist wxstd.mo files in the samples section, not as part of the main distribution (and only in 2 languages, too). Any idea?
The easiest way is to install poEdit, download po file, open in poEdit save and voila, there's .mo file :)
Yep, that's what I did for testing, although poEdit corrupted the file on the first attempt, it worked nicely after that. Very nice program :)
And there's also another minor problem: the default installation does not create locale in /usr/local/share/codeblocks, so every single time I run Code::Blocks it complains because it's unable to enumerate the contents of that directory. Creating it solves the problem, but it should be evaluating the existence of that directory first, or be sure make install will create it.
Ah yes, did not think of that... We should make sure the directory is created by make or update.bat. Or, we could simply add a wxNullLog, or both :)
-
please commit the changes to avoid that message box.
In order to avoid to many people asking about this, I will not release a nightly build today (unless it get's fixed very soon ;-) ) . Could it be fixed by tomorrow please ?
-
please commit the changes to avoid that message box.
In order to avoid to many people asking about this, I will not release a nightly build today (unless it get's fixed very soon ;-) ) . Could it be fixed by tomorrow please ?
sorry, but in the nightly build you can easily create this directory and all goes well,
no reason to be afraid ... 8)
-
well we will just wait till tomorrow, so no hacking is needed ;-)
-
Thomas : did you decide on how to solve it ? wxNullLog or even explicit check for the directory ?
could you pinpoint me to the code, I'd like this to be resolved.
-
Already committed that :)
The app is creating the directory at startup. It still needs a wxNullLog though (is in place already too), to catch the case of a user deleting the subfolder of the currently selected language.
After adding approximately the 25.000th wxNullLog to the code, I start asking myself why we don't add one wxNullLog to CodeBlocksApp::OnRun.
All wxWidgets messages are all bullshit anyway, nobody wants to read them, there is never anything useful in them. They only hinder your workflow by throwing up a modal box that tells you something which does not matter and which you don't want to know (and which sometimes is not true, but is really just wxWidgets' bad implementation, as in "path contains too many '..'").
We're probably saving considerable code size and execution time by removing all the many wxNullLogs and inserting one early at startup.
Or, is there anyone who actually wants to read them?
-
Or, is there anyone who actually wants to read them?
The only legit message I 'm interested in seeing is when a plugin can't be loaded because of missing symbols. The popped-up message contains the function signature that couldn't be located.
But I 'm fine with removing everything and putting one wxLogNull in main app code: I could just temporarily remove it to see what I 'm interested in :).
-
Or, is there anyone who actually wants to read them?
The only legit message I 'm interested in seeing is when a plugin can't be loaded because of missing symbols. The popped-up message contains the function signature that couldn't be located.
But I 'm fine with removing everything and putting one wxLogNull in main app code: I could just temporarily remove it to see what I 'm interested in :).
If you're going to modify that section of code, could you do a DBGLOG() of that particular message or symbol that's missing.
Each time this happens, we have to comment out the two wxNullLog statements to view the missing symbol.
thanks
-
Or, is there anyone who actually wants to read them?
The only legit message I 'm interested in seeing is when a plugin can't be loaded because of missing symbols. The popped-up message contains the function signature that couldn't be located.
But I 'm fine with removing everything and putting one wxLogNull in main app code: I could just temporarily remove it to see what I 'm interested in :).
If you're going to modify that section of code, could you do a DBGLOG() of that particular message or symbol that's missing.
Each time this happens, we have to comment out the two wxNullLog statements to view the missing symbol.
thanks
Unfortunately I can't. I have tried to access the error message but it is not available...
So my solution is to comment-out those two wxLogNulls.
At least, with Thomas' proposal, we will only have to comment-out only one...
-
Unfortunately I can't. I have tried to access the error message but it is not available...
So my solution is to comment-out those two wxLogNulls.
From what I can see by looking at the wxWidgets sources, the function showing this error message
- is implemented under POSIX
- is entirely missing under Windows (cannot even find a declaration?)
- consists simply of a call to dlerror()
Thus, it would probably suffice to call dlerror() for Unices and FormatMessage(GetLastError()) for Windows, if you're interested in dumping the extended info to the debug log.
-
Unfortunately I can't. I have tried to access the error message but it is not available...
So my solution is to comment-out those two wxLogNulls.
From what I can see by looking at the wxWidgets sources, the function showing this error message
- is implemented under POSIX
- is entirely missing under Windows (cannot even find a declaration?)
- consists simply of a call to dlerror()
Thus, it would probably suffice to call dlerror() for Unices and FormatMessage(GetLastError()) for Windows, if you're interested in dumping the extended info to the debug log.
Thanks, will have a look.