10 replies to this topic

[Reyhn]

Hi,

I thought it would be cool to have as much multi-language games, emu etc as possible, because that's openness too
So why not have a translation requests thread where people can put their texts, dialogs etc and ask for a foreign language ?
I just finished my exams and now have plenty of time, so I would be glad to contribute to development by translating into french.

I'm certainly not an expert but I understand English pretty well so ...

watcha think ?

[Pleng]

The way most content management systems deal with languages is to include a 'language.php' file which has a list of definitions, such as:

$EMU_LOADROM = "Load Rom"
$EMU_RESUMEGAME = "Resume Game"
....
$SYS_EXIT = "Quit"
$SYS_HOME = "Home"
$SYS_SAVE = "Save"

Then when the system wants to implement this they just call the constant. So they could create some code that looked a bit like:

button.text = $EMU_LOADROM

to set a button's text to "Load Rom". Change the language.php file to define $EMU_LOADROM t be "FlipFlop" and every time the constant is called the text displayed will be "FlipFlop".

Now I don't know if something like this is possible using Environment variables, and if it is, what sort of an impact it might have on memory usage or performance, but it would be quite cool to see it implemented in the OS. Then the only hurdle would be to get developers to actually make use of it!

[Tom`]

In C/C++ using the preprocessor would be a much better way than environment variables, I would guess. That way you could have something like

#ifdef ENGLISH_LANG
#include <english.h>
#else
// (other languages, etc.)
#endif

// english.h

#define EMU_LOADROM "Load Rom" // or should it be a const char* maybe?
#define EMU_RESUMEGAME = "Resume Game"

and so on.

NOTE: I don't really know C/C++, only learned it in school (supposedly), so that could be completely wrong or a bad idea...

[dflemstr]

A language neutral alternative would be to use external translation files.

For the Box, I use so-called "properties" files, which use a file format similar to INI-files, only that "properties" files lack sections.

The way the system works is that I request a string, e.g. "user.email.validationSent", to display to an user with e.g. the locale "de_DE". The system will then first try to load "core_de_DE.properties", look for the string there, then load "core_de.properties", and then finally fall back to "core.properties" if the string wasn't found.

The advantages of this system is that a translation doesn't have to be complete for it to be usable, and also that you don't have to recompile the application to load new translations. It's also very easy for translators to do their thing, since the syntax of the translation files is dead simple.

I currently have translations for English, German, French, Dutch and Swedish; you can view the translation files here: http://github.com/dflemstr/box/tree/develop/src/main/resources/translations

[Pleng]

In C/C++ using the preprocessor would be a much better way than environment variables, I would guess. That way you could have something like

 #ifdef ENGLISH_LANG
 #include <english.h>
 #else
 // (other languages, etc.)
 #endif

 // english.h
 
 #define EMU_LOADROM "Load Rom" // or should it be a const char* maybe?
 #define EMU_RESUMEGAME = "Resume Game"

and so on.

NOTE: I don't really know C/C++, only learned it in school (supposedly), so that could be completely wrong or a bad idea...

The trouble is you then have a (programming)language specific approach with a (spoken)language being hard complied in. If you're including english.h then the complied output will be in English

The suggestion for environment variables means you could change the variables in your language.sh (for example), or install a new one for your chosen language, and ALL apps would instantly show the new definitions without needing to be recompiled. So on runtime the application could import the envars with something like (and I don't remember c, even though I only did it a term ago so please excuse any syntax or continuity errors):

varLoadRom = system('echo $EMU_LOADROM');
varResumeGame = system('echo $EMU_RESUMEGAME');
varQuit = $SYS_EXIT('echo $SYS_EXIT');

/* Display a basic menu */

printf ("1) %s /n 2) %s /n 3) %s", varLoadRom, varResumeGame, varQuit);

exit 0

So you see, when the language file is updated, the game will dynamically update itself on runtime

[dflemstr]

Having too many env vars is going to slow down the system, and all of them will have to be kept in memory, so you'll get memory issues.

Keeping the current user locale as an env var might be a good idea, and it'd then be up to the individual app to load the correct translations from persisted files.

[Pleng]

Having too many env vars is going to slow down the system, and all of them will have to be kept in memory, so you'll get memory issues.

Yea that's what I was worried about.

Keeping the current user locale as an env var might be a good idea, and it'd then be up to the individual app to load the correct translations from persisted files.

Or have some kind of language.xml which would symlink to (for example) english.xml and then, yea, the app could load it at runtime.

Still it's probably all a little too late to implement now!

[dflemstr]

Anyways, how would you coordinate the translations? Would all apps in the system use the same file? If yes, how would you get the thousands of strings from the hundreds of applications that are in the OS in there? That'd be a hell to manage!

No, I think it's best for each app to implement its own localization system; the OS *does* tell all apps which locale it uses, so it should be np.

[Pleng]

Clearly it wouldn't work with every application. But it could be there as a support tool for apps that DO want to implement it. It's not going to translate huge blocks of text in RPG games, but it's a nice little feature for commands which dont vary from (for example) emu to emu (Save State, Load State, Select Save Slot, Load New Rom, Quit) it'd be nice to have an extensible framework where variables can be loaded in from.

That way a new language pack can be released, and any application which made use of the framework would automatically have its system commands etc transtlated.

[dflemstr]

Clearly it wouldn't work with every application. But it could be there as a support tool for apps that DO want to implement it. It's not going to translate huge blocks of text in RPG games, but it's a nice little feature for commands which dont vary from (for example) emu to emu (Save State, Load State, Select Save Slot, Load New Rom, Quit) it'd be nice to have an extensible framework where variables can be loaded in from.

That way a new language pack can be released, and any application which made use of the framework would automatically have its system commands etc transtlated.

Oh, well you should have a look at the Haiku Locale Kit; they have an interesting solution for this. But it'll be impossible to produce something centralized, I think, because of how different all applications are.

I mean, some of them will be written in languages that can't access environment variables (actually, most languages CAN'T access env variables) so your only option would be to use something like CouchDB and a HTTP server for translations (which would work beautifully if the Pandora was a tad faster ) or a well-known XML file in e.g. /etc/pandora/translations/...

[Pleng]

yea an extensible XML language pack was what I was thinking towards the tail end of the thread. Maybe a directory structure along the lines of:

Languages
--UserLanguage (symlink --> (for example)English)
--English
----system.xml (containing variables such as open/save/save as/edit/exit/quit...)
----editor.xml (cut/copy/paste/select/crop/insert/delete)
----emu.xml (load new rom/save state/load state/select save slot/frameskip...)
----gfx.xml (brightness/gamma/white balance....)
----audio.xml (scrub/loop/punch in/punch out...)
--French
----system.xml
----editor.xml
----emu.xml
----gfx.xml
----audio.xml
--German
----(...)
--Spanish
----(...)
--Italian
----(...)
--(...)

Then an app that wanted to make use of translation features could load up whatever files it required from UserLanguage and pull out any of the variables it needed.