Page 2 of 2

Re: Multilanguage support

PostPosted: 27 Apr 2011, 16:11
by oln
Hm, may need to bundle the lib for that for VS then, but that should be okay, since it's quite small.

Re: Multilanguage support

PostPosted: 27 Apr 2011, 16:24
by StefanP.MUC
Hmm, I added the FindICONV.cmake file, but it still doesn work... Still undefined reference to libiconv...

Re: Multilanguage support

PostPosted: 27 Apr 2011, 17:57
by oln
Did you actually tell it to link to it though?

Re: Multilanguage support

PostPosted: 27 Apr 2011, 18:25
by StefanP.MUC
Where in the cmake files do I have to do this?

Re: Multilanguage support

PostPosted: 27 Apr 2011, 18:33
by oln
You can look in src/CMakeLists.txt to see how it's done with the other libraries. I would assume it linking to libiconv will be similar.

Re: Multilanguage support

PostPosted: 28 Apr 2011, 09:12
by StefanP.MUC
I decided to drop the iconv lib. It is only used in less than 10 lines in tinygettext, I think I can code a short workaround for it. Then we don't need to have a new dependency.

Re: Multilanguage support

PostPosted: 28 Apr 2011, 10:48
by svenskmand
I am also a bit puzzled why we would need a external library, except for using the same fileconventions as say GNU Gettext/Tinygettext. As we would only need a single method string gettext(string key) which finds the correct translation in the currently selected language.

Re: Multilanguage support

PostPosted: 28 Apr 2011, 11:09
by oln
Well it shouldn't be a bit deal to bundle it. It's basically a function to convert between character encodings. I can re-add this later and fix the linking if needed.

Re: Multilanguage support

PostPosted: 28 Apr 2011, 11:51
by StefanP.MUC
The original tinygettext had a wrapper around iconv with a "string convert(string original)" method that was called three times. I simply removed the calls for convert() and passed "string orginal" directly to whatever it was passed, making the whole iconv dependency unneeded.

Considering the following three points, we probably won't reach the calls to convert() anyways.
- I didn't try to fully understand the tinygettext code, but the convert() calls were deep down in a lot of nested if-clauses.
- The first working versions of tinygettext (originally made for SuperTux) didn't have it at all (seems it was added when they made it a standalone project to support very rare and very strange encoding cases).
- In their TODOs is also a comment about removing/working around the dependency of iconv (so in later official versions it's likely do disappear anyays).

Re: Multilanguage support

PostPosted: 28 Apr 2011, 13:59
by oln
Okay, then your approach is probably the right one. Maybe we should talk to the stkl devs about the purpose of it.

Re: Multilanguage support

PostPosted: 28 Apr 2011, 15:37
by svenskmand
I currently get this error when building the game on Linux:
{l Code}: {l Select All Code}
CMake Error in src/CMakeLists.txt:
  Cannot find source file "Translation.cpp".  Tried extensions .c .C .c++ .cc
  .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx

Re: Multilanguage support

PostPosted: 28 Apr 2011, 15:42
by oln
Maybe stefan forgot to upload it. Happens :p
Also, we should try to use
{l Code}: {l Select All Code}
#include "tinygettext/header_file.hpp"

if we are not already to significate that it is separate from the rest of the code.

Re: Multilanguage support

PostPosted: 28 Apr 2011, 15:45
by svenskmand
How did I check out only the latest revision of the development branch from git, i.e. without cloning the entire repo?

Re: Multilanguage support

PostPosted: 28 Apr 2011, 19:56
by StefanP.MUC
Sorry, forget to add it... It's now on git.

Re: Multilanguage support

PostPosted: 29 Apr 2011, 16:35
by oln
Also, you shouldn't bother to do style changes to the tinygettext. It's a separate project, so try to keep with their code style.

Re: Multilanguage support

PostPosted: 29 Apr 2011, 16:57
by StefanP.MUC
Good news: The basic translation framework is done and working. I just tested and commited it.

What needs now to be done:
- The GUI needs to be made "translatable" in the code. Pseduocode:
GUIelement.Text = _("english text");

- create .po files with the translation.
- add a menu to select the language
- if no user config exists (first run of the game, e.g.), an auto-detection of the system language would be nice. This should work already, but it doesn't. tinygettext has a function to set it from "setlocale()" but it crashes.

Yeah, I was also thinking a while if I should change the code style of tinygettext. But considering the following I came to a "yes".
Firstly, I'm not sure if tinygettext is still maintained by the authors. Last change to the official codebase is almost 9 months ago (currently that's already around one third of it's overall lifetime).
Secondly, considering the changes I made (and possible will make in the future) to make it work with OD (removing a whole class, adding a function, some performance and compatibility changes), it's almost "merged" int OD. I'm also thinking about replacing some of its functions with already existing functions from OD, like getting file lists etc (then it would be really merged).

Re: Multilanguage support

PostPosted: 12 Jul 2011, 01:20
by MyEmail
I would recommend leaving lingual support till the end. Its a enormous hassle, and TBH you don't need it done till a product is ready to deploy (ie when its done). So, use wide characters for GUI code and such so that multi-lingual support can by added, but I wouldn't go past that.

Re: Multilanguage support

PostPosted: 12 Jul 2011, 09:48
by sireus
1) Multilingual support is relatively easy. Multilingual != Unicode.
2) Unicode isn't that hard either, most likely the only things that need to be adapted are font rendering (unless you use an external tool to do that for you, which would most likely support unicode anyway). You don't have to use ...w... functions and variables for anything, actually (except if you want to do things like counting actual characters, not string length).
3) I'd recommend starting as early as possible. That's definitely easier than having to adapt everything in the end. And besides, we all know this "we'll do it later" approach, don't we? :D

Re: Multilanguage support

PostPosted: 12 Jul 2011, 16:42
by MyEmail
Alright, suit yourself. Instead of focusing on more needed features (graphics, game-play, networking, etc etc) go ahead and gander your time away on this "easy" feature.

When will Russian be supported? Perhaps French? Maybe Spanish, Chinese, Arabic, Portuguese, Japanese, German, Korean, Italian, Polish, Persian, Thai, Romanian, Dutch, Greek, Czech, Swedish, and Slovak? Hopefully soon since those languages compose 90% of your client-base, and since your devoting so much time to such an easy feature.

Do note that in the early stages of a game the text changes very often, and each release the dictionaries for each language will have to be re-translated (this compounds in later stages, when large amounts of text are in the game).

No really, coming from an experienced developer and team-lead, saving the language crap till the end is the way to go. But, do whatever you see best.

PS: Oh, and ((Multilingual != Unicode) == false), whereas ((Multilingual == Unicode) == true)

Re: Multilanguage support

PostPosted: 12 Jul 2011, 16:46
by StefanP.MUC
Well, the actual translation framework is working. All that is missing is:
- some auto-detection of the system langauge (not so important, only relevant for first-start of game)
- a langauge selection menu (this will be done altogether with a complete option menu)
- actual strings that can be translated :D

I did stop working on this last point because I still need to figure out what's the best practice with CEGUI (but according to their forums there's no best method... So we need to figure out what's the easiest way to go there ourselves).

Unicode is not the problem here. The strings are loaded from some Unicode-encoded text files and are directly passed to CEGUI (which can handle Unicode).

Besides CEGUI, there won't be lots of text anyways. Only the (scripting) console, but we don't translate the scripting commands. ;)

Re: Multilanguage support

PostPosted: 13 Jul 2011, 01:53
by svenskmand
The multilanguage support should be implemented early, no discussion there. But doing the actual translations should be done later in development where we more or less have all text strings fixed.

Re: Multilanguage support

PostPosted: 13 Jul 2011, 03:46
by MyEmail
svenskmand {l Wrote}:The multilanguage support should be implemented early, no discussion there.

Actually, there is. But its irrelevant at this point since StefanP.MUC says its already implemented. Just, please, don't even think about doing the translations until a stable/final release is made.