Re: [Freeciv-Dev] Internationalization

[Artur Biesiadowski <abies@xxxxxxxxx>]

David Pfitzner wrote:

> So probably, the ruleset files should have a section giving
> lists of languages, and then a list of translated names for
> each language.  The server would read in all the translations,
> and send to a client the default-language names and the names
> in the client-prefered language, so the client can do translations.

No, I would think about keep logic and translations separate. If game
uses modified rules then translations still apply - Batlleship is a
Battleship regardless of amount of hp it has. If rules will modify NAME
to something else, then it will just not get translated - most
reasonable thing that can be done.

Translations should be kept in one or more files which only purpose is
translation - this way no game logic changes have to be passed to every
translation.

Of course, keeping sync between large files like help or readme is quite
hard, but there is no way to do this painlessly.


> For generic helptext, each entry in the helptext could have multiple
> sections for different languages; or there could be multiple separate
> helpdata_*.txt files, one per language; or multiple files where the
> default is read in first and then a language-specific version is
> read-in after and overrides some entries.   An issue here would be
> whether one of these methods makes it easier to keep translations
> up-to-date, but I'm not sure which...
The way that would allow reliable checking of changed descriptions etc,
would be to keep every subject in different file (and keep all of them
in zip file for example). After that translation could be taken as
"correct" if it is created later than original file.
Somebody could later provide tool which would compare zips and display
not actual entries side by side for easy correction...


> 4. Sentence generation, grammatical contructions.  In some places
> freeciv automatically generates some sentence elements, such as
> using "a" or "an" before a noun, or adding a location qualifier
> to a message.  I guess this will cause some problems.

I'm afraid that it just can't be done correctly in generic manner. In
java for example there is something called MessageFormat allowing to do

MessageFormat form = new MessageFormat("The disk \"{1}\" contains
{0}.");
double[] filelimits = {0,1,2};
String[] filepart = {"no files","one file","{0,number} files"};
ChoiceFormat fileform = new ChoiceFormat(filelimits, filepart);
form.setFormat(1,fileform);
Object[] testArgs = {new Long(12373), "MyDisk"};
System.out.println(form.format(testArgs));

It looks like localizing all string above would solve the problem. But
for example in polish, you need to use different form for 0, 1, 2-4,
5-21, and then for things ending with 2-4 use second entry and for rest
last entry. I suppose that in other languages there are other such
rules. 

One way to solve this would be collect all comunicates that can give
problems and put string creation rutines in separate c file(s) and allow
translating them. Then some smart preprocessor (or just linker) would
add missing routines from default english version and voila.

BTW, city names could also be localized... this could be quite funny if
one player would see Munich and second Munchen :) and of course polish
would need at least few declinations of each city to be able to
construct correct sentences...

Artur