Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Internationalisation update
thomas:
--- Quote from: byo on June 30, 2007, 06:23:50 pm ---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.
--- End quote ---
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?
--- Quote from: byo on June 30, 2007, 08:26:35 pm ---The easiest way is to install poEdit, download po file, open in poEdit save and voila, there's .mo file :)
--- End quote ---
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 :)
--- Quote from: Ceniza on July 01, 2007, 12:31:57 am ---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.
--- End quote ---
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 :)
killerbot:
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 ?
tiwag:
--- Quote from: killerbot on July 01, 2007, 06:06:51 pm ---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 ?
--- End quote ---
sorry, but in the nightly build you can easily create this directory and all goes well,
no reason to be afraid ... 8)
killerbot:
well we will just wait till tomorrow, so no hacking is needed ;-)
killerbot:
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version