Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Kupferdrache]

There is a comunity translation project in progress now again (atm only as replacementmod). so I would ask if it is possible to add a feature to choose between different (language) buildin?- textversions via init files or options menu so translated files could be used from a subdirectorie insteed of of replacing files.

sudirectorie coult be named /en or /enGB /enUS for the official files, so other like /de /fr /jp /ru or /deDE /esMX /ptBR could held a copy of official files, if untranslated yet or localizied one.

What do you think about it? Would be great if we get this as core feature anytime.

Kind regards

[Matoro]

Well it could be useful, but I think it's quite low priority. If you can get over DF:s learning curve, then English won't be problem.

[Kupferdrache]

Not for me but thats not the point, the point is many people like to play in their nativ language if possible (including me). Low prio is also no problem, that will give us the time to polish our current translation so bay 12 don't need to translate all by their own, but verify our and make it offical, or go an complet other way.

[breadman]

You may be underestimating the amount of work involved.

Translating the raws and other external files will get you perhaps 60% of the way there, at least for languages using the Roman alphabet.  Unfortunately, doing so will involve creating a system to switch the raw directory based on a selected language.  Worse, certain key bindings should also be translated, but would have to be loaded before the user could select a language, or re-loaded on language selection, unless the language could only be selected through editing the init.txt file.

Translating the hard-coded strings will contribute perhaps another 25%, but will require something like gettext for on-the-fly translation.

Another 5% will involve converting various routines to deal with quirks in each language.  Things like inserting articles into names and descriptions currently make certain assumptions that don't hold true outside of English.  A new tag might be required, specifying the grammatical gender of every object in the game.  This can be eased slightly by moving more of the hard-coded items, buildings, and materials into the raws, but that alone is a messy project.

The last, hardest 10% will be changing the output routines to use true Unicode and/or a large enough tileset to support non-alphabetic languages, and making every potentially conflicting code point configurable.  Again, rawification will help here.

Worse, the translation effort itself will involve someone fluent (or at least proficient) in each target language.  Given the way releases are handled, these language packs will probably be distributed externally, lagging some time behind the official release.  Meanwhile, the bug tracker will be inundated with complaints that this or that language doesn't work right, or that some generated sentence is ungrammatical in certain situations.  This is exactly the kind of stressful situation Toady has decided to avoid by not catering to third-party interfaces.

For a quick gauge of the effort required, try to combine the English, Chinese, German, Japanese, and Spanish versions of NetHack into a single executable.  Then translate it into Arabic.

That said, it would be nice.  When the source goes public, I have no doubt that someone will try it.  Meanwhile, this becomes another argument for moving hard-coded stuff into the raws when possible and convenient.

[Kupferdrache]

Thanks for enlighting me about the behind the senses part of this project. A lot more work to do then I estimatated, when like here later i18n and l10n isn't  prepared from beginning.

Our project uses at the moment the buildin keys even they don't match the proper language, but keep a comant referenz alive and rely on user defined keys, if wished.

I hope you can ad this as Powergoal 184 (183 seems to be the last til now) to the list.

Kind Regards

[Trif]

I think it's covered by Core54.

Core54, TRANSLATION SUPPORT, (Future): Announcements and other interface text needs to come out of the game and be placed in an editable format to support any potential translators, though current font implementations restrict this process at the moment if non-ASCII characters are to be involved.

[Kupferdrache]

maybe the use of  google Noto Sans helps to get out of this problem with nonascii charaters.

[Mesa]

The grammar and orthography of certain languages (like Polish, for example) and randomized nature of DF would make this nigh-impossible.
A coding mega-project. Even if DF is a mega-project in and out of itself.