Internationalization Plan

Originally FreeTrain was a Japanese game. This project started as a translation into English, but now (other than running the original version) there is no way to run our version in Japanese or - should a translation be contributed - any other language.

This thread is for discussing how we should add the capability to localize the game into other languages.

The best idea would be to use PE and i18n, or whatever the correct terms are...
Another thing I never got around to.

http://www.codeproject.com/KB/cs/multilingual_pplication.aspx

The above has a link to using resource files for translations and it makes it pretty straight forward.... we just need 'codes' for the strings used throughout the game.
i.e.
TAO_SDL_NOT_FOUND="You have not installed the TAO SDL Framework, please download it from http://www.taoframework.com/"

I believe we should use some form of nice framework for this...
The other issue is that the 'manager' will need to be an external library that all plugins can use... that then means that they need to define strings in it to use it... which wouldn't make sense if people want to use it out of the projects solution file... which means that we need to store the resource files 'local' to the plugins but the guts/core/programming in a library that they can include. ok.


omg..doublepost.

OK, I've got the internationalisation working with the concept of the resourcemanager, etc... as shown in the first link of the previous post. The next trick is to work out how to deal with plugins that are created outside the solution (since their strings therefore wouldn't be included with the core translation).

I was thinking that the best way would be to have the plugins declare at least english strings (and also the developers native language) in the constructor and have these passed to the translator class on first load. this would mean that the translator will then keep these itself and report back saying that there are new strings to translate. it'd then be up to the community to update the translator as to the other languages that these strings should be translated to.

Or we could go even funkier and have a web service (cached locally) of the translated strings so that when the user downloads a new plugin that their strings are automatically downloaded.

... thinking out loud ....

I think the plugin strings just need to use some form of register hash 'getText("TAO_SDL_NOT_FOUND", "en")' but that seems prone to problems.

Not an easy one as each solution has problems. Perhaps the plugin author just has to be responsible for including the translations, and the community for providing them, and the project a policy that each plugin has to have - at a minimum - the english translation to be included in the (un)official downloads on Sourceforge.

*shrugs* wish I could be more insightful.

That is the idea... the issue is that when a user adds plugins that are trying to access strings that the core doesn't know about ... say the a highway plugin wants the text for "Build Highway" --> BUILD_HIGHWAY and the core doesn't have that defined... I don't actually know what the application will do.
I suppose then the answer is to have little-libraries included with the plugin for the Translation manager to load and use.
Or, of course, the creator of the plugin tells us the strings and then we include them... but that would then mean that the user has to update the language files before being able to use the new plugins... this could be a simple message upon application startup and the plugin could have a default language so that the user can proceed without having to download stuff straight away... they just might have an english plugin and a japanese interface.

OK, heres the basic idea... Provided a patch so as to not ruin any of Dave's work... just yet...

Dave, can you look over this and tell me what you think?

... Simple additional class that provides the strings for each language. The language is loaded at the start of the application, defaulting to english if no match.
...There is now a post-build command to create the resource files... this requires RESGEN.EXE which also exists in mono... the script just needs to check the platform and then run the appropriate tool. Stupidly, that tool on windows is not in the default path and so on my machine I copied the EXE to the project directory; but we need to sort this out... i think on windows we could put the full directory name in there... which is buried in Program Files... but I'm not so sure it's the same on all versions of visual studio.

Anyway.. for all's perousal.

warning: seems tortoisesvn is having issues reading the japan binary and is listing the us language file twice...
Patch File
here is the japan language file

Charles, please allow patch/diff attachments on the forum!!

I checked in the changes. Looks good, but we should see there is a way to not use a post-build task. The task fails on my Windows and Linux machines. The path is the issue on Windows and on Linux the util is called resgen2.exe. I know that you can put resource strings into the Resources class under properties, but I have only done that with English before, never with multiple languages.

I attempted to add things to the Resources view in Visual Studio and failed... I have no idea how to do that but will dig into it tonight.
Thanks for checking it out... the main issue with the build script is on my windows machine I had copied resgen.exe to my project directory... was about to check that into the tree but didn't think it would work on Linux... but I do like the idea of using the proper resources view... will see what I can achieve.

Hi,

I added the english and Japanese strings into Resource files and modified the Translator class to call them. Bringing up the Japanese interfaces does not display the charaters correctly though. They come out as blocks and such. Is it a font issue?

I get blocks in the time display when trying to use the SDLTTF libraries... but in the rail controller I see beautiful japanese scripting
And i love the way you've integrated it into the solution, thanks heaps.

I would think so. If you don't have Japanese fonts installed then it will look odd (usually just, as you say, blocks).

that's the thing.. i do.. i fed in all sorts of TTFs and it still wouldn't show the characters... I saw that there were a unicode and utf8 procedures... the former shows squares the latter shows question marks.

and a quick question... should just publicise the resourcemanager so that we can get to the internal static strings instead of calling through the translation class?

Really glad that i18n is falling into place. It has been a concern of mine since translation was initiated. Feel free to ask me if there are any ambiguities in the Japanese strings.

I added a French translation to the project. My French is not very good, so feel free to correct any mistakes.

And I added a Swedish one. Hope I didn't mess anything up too bad!

And I added a Swedish one. Hope I didn't mess anything up too bad!

You did... Please also check in Resources.sv-SE.resx



...Now everyone just needs to dig in and add the strings for EVERYTHING that requires translating

I've done 2 Controllers and ... an Error message which didn't previously exist... I think I'll finish off the /core/controllers stuff, so if anyone wants to work out strings in another directory of core and start there then please, go for it

And I added a Swedish one. Hope I didn't mess anything up too bad!

You did... Please also check in Resources.sv-SE.resx

Oops. I did check in the file, but under the wrong name. Should be resolved now.

Thanks Daniel, works now

Charles, I hadn't had any issues on Windows when the Japanese culture tried to use a string that wasn't defined in it's language... it would just display the english culture string and then it became very obvious that the string was missing... but I take it Mono (or some such) doesn't handle the missing strings as elegantly? Neat work on that either way.

I've stopped with the updating of the strings for now until we get some structure and momentum on how to deal with the GUI.