Red Eclipse translations?

[DroiD]

Was wondering if Red Eclipse could do translations (except chat)
For spanish you can use me

[ZeroKnight]

Do you mean menu translations? I don't suppose that would be too hard, since there's not many menus.

[DroiD]

yeh menu translations
something like
edit profile > language > Spanish (exec "data/languages/spa.cfg"

[ZeroKnight]

Hmm, yeah! It might require a change in the way the Main GUI is initially created, but it very well could be done. I actually see a few different ways it could be done.

First Way:

Instead of running "menus.cfg" at start, a separate cfg is launched. This will include the profile setup GUI where it contains the current name and color set, as well as a radio list (or whatever) to select user language. Then after the details are set and the user hits okay, it will from then on launch a copy of menus.cfg based on selected language.
ie. "data/menus/" and inside is "menus_en.cfg", "menus_es.cfg", "menus_de.cfg" etc. etc.

The only caveat to this method is that the weight of the RE package will increase with every added language.


Second Way:

Using the same language getting method as above, there could be a "translation file" of sorts included with the RE package. What it could contain is just multiple variables that are lists of terms for the menu items. And menus.cfg could be modified so that instead of displaying string literals, it could reference the language that the user set, and call on the particular language list var, and get the proper string.

For example, here's the "translation file":

{l Code}: {l Select All Code}

lang_en [ "<some menu item name>" "<another menu item name>" "<yet another>" etc. etc. ... ]
lang_es [ "<some menu item name in spanish>" "<another menu item name in spanish>" etc. etc. ... ]
lang_de [ ... ... ]


And the elements would all have the exact same order, just the different translation for each. That way, the menu text could be created something like:

{l Code}: {l Select All Code}

guitext [ (at $userlang <index of needed menu string>) ]

And the modified profile set gui could include:

{l Code}: {l Select All Code}

[ ... ]
guiradio "Spanish" [ userlang = lang_es ]


Third Way:
Probably the most unrealistic, but you could offer download packages of RE in each language, or create a special download assembler of sorts that would always include the necessary base files and all files that do not rely on language, and depending on chosen language on the download page, the files that coresspond to that language get added to the "package" of sorts. If this needs more clarification, I will provide it.


Those were my ideas.

[EDIT]
Just fixed my many grammar mistakes. Was in a hurry while writing ^^"

[DroiD]

i like the first one i start with it tomorrow

[srbs]

Second Way.5:
in each file: en_us.cfg, etc (using language naming conventions)

{l Code}: {l Select All Code}

NAME_STRING = ""

then in the menus:

{l Code}: {l Select All Code}

guitext $NAME_STRING

instead of putting everything in a list, because there are waaaay too many strings to translate to be put in one single list.

Also, this allows doing:

{l Code}: {l Select All Code}

exec en_US.cfg
exec es_ES.cfg

and having english strings be defaulted if untranslated

[ZeroKnight]

I think I see what you mean. menus.cfg will have all of the same string vars, with each locale in a different config, and the vars go like: $NAME_STRING, $OPTIONS_STRING, $SERVERLIST_STRING, etc. etc.

Correct?

[qreeves]

I wouldn't suggest using variables like that, would become clusterfuckish, lol. Just make it load a different menu file.

[srbs]

I wouldn't suggest using variables like that, would become clusterfuckish, lol. Just make it load a different menu file.

I agree here, but maintaining changes to the menu on all translations can be painful at times.

[ZeroKnight]

I suggested separate menu files just to throw up an option. However, I don't think that particular option is a good choice, and here's why: Package Weight.

Looking at the PortableApps platform, they support 54 languages. menus.cfg is 86KB. Assuming we'd ever support the same amount of languages, 54 copies of menus.cfg is a hefty ~4.6MB for JUST menus and text.
However, the way they do it is more or less what I described in option 2, having the locale files.

Here's a snippet from their German locale file (for the portable apps platform itself)

{l Code}: {l Select All Code}

[PortableApps.comLocaleDetails]
Name=German
LocalizedName=Deutsch
Version=2.0
ContributedBy=Germanophone Team
LocaleID=1031
LocaleWinName=LANG_GERMAN
LocaleCode2=de
LocaleCode3=ger
LanguageCode=de
Localeglibc=de
Codepage=1252

[GENERAL]
BUTTON_OK=&Ok
BUTTON_CANCEL=&Abbrechen
BUTTON_REVERT=&Zurück
BUTTON_YES=&Ja
BUTTON_NO=&Nein
BUTTON_REMIND=&Später erinnern
COLOR_PINK=Rosa
COLOR_RED=Rot
COLOR_ORANGE=Orange
COLOR_YELLOW=Gelb
COLOR_GREEN=Grün
COLOR_BLUE=Blau
COLOR_PURPLE=Lila
COLOR_VIOLET=Violett
COLOR_BLACK=Schwarz
COLOR_WHITE=Weiß
COLOR_GRAY=Grau
COLOR_SILVER=Silber
COLOR_BRONZE=Bronze
COLOR_GOLD=Gold
COLOR_BROWN=Braun

[FORM_MAIN]
APP_MENU_RUN=&Ausführen
APP_MENU_RUN_AS_ADMIN=Als A&dministrator ausführen
APP_MENU_RENAME=Um&benennen
APP_MENU_HIDE=Ausb&lenden
APP_MENU_MOVE_TO_TOP=An den An&fang stellen
APP_MENU_MOVE_TO_BOTTOM=Ans &Ende stellen
APP_MENU_SHOW_HIDDEN=Ausgeblendete Symbole an&zeigen
APP_MENU_REFRESH=A&ktualisieren
APP_MENU_START_AUTOMATICALLY=Automatisch s&tarten
APP_MENU_EXPLORE_HERE=&Suchen
APP_MENU_ALWAYS_SHOW_ALL=&Immer alle Anwendungen anzeigen
APP_MENU_SHOW_CATEGORIES=Kate&gorien und alle Anwendungen anzeigen
APP_MENU_ALL_APPS=Alle &portablen Anwendungen
APP_MENU_BACK=Zurü&ck
APP_MENU_CATEGORY=&Kategorie
APP_MENU_CATEGORY_ADD=Kategorie &hinzufügen
APP_MENU_CATEGORY_ACCESSIBILITY=Barrierefreier &Zugang
APP_MENU_CATEGORY_DEVELOPMENT=&Entwicklung
APP_MENU_CATEGORY_EDUCATION=&Bildung
APP_MENU_CATEGORY_GAMES=&Spiele
APP_MENU_CATEGORY_GRAPHICS_AND_PICTURES=Grafik und &Bildbearbeitung
APP_MENU_CATEGORY_INTERNET=&Internet
APP_MENU_CATEGORY_MUSIC_AND_VIDEO=&Musik und Video
APP_MENU_CATEGORY_OFFICE=&Office
APP_MENU_CATEGORY_OPERATING_SYSTEMS=Betriebss&ysteme
APP_MENU_CATEGORY_SECURITY=Si&cherheit
APP_MENU_CATEGORY_UTILITIES=&Werkzeuge
APP_MENU_CATEGORY_OTHER=Sons&tige
APP_MENU_PREFIX_APP=Anwendung
DRIVE_SPACE=$DRIVEFREE von $DRIVETOTAL frei
ICON_DOCUMENTS=&Dokumente
ICON_MUSIC=&Musik
ICON_PICTURES=&Bilder
ICON_VIDEOS=&Videos
ICON_EXPLORE=D&urchsuchen
ICON_BACKUP=S&ichern
ICON_MANAGE_APPS=&Anwendungen verwalten
ICON_OPTIONS=&Optionen
ICON_HELP=&Hilfe
ICON_SEARCH=&Suchen
ICON_MENU_CHANGE_PATH=&Verzeichnis ändern
ICON_MENU_CHANGE_ICON=&Symbol ändern
ICON_MENU_CHANGE_DOCUMENT_ROOT=Pfad für &Dokumente ändern
ICON_MENU_RESET=Auf Standardwerte &zurücksetzen
MENU_MANAGE_APPS_CHECK_FOR_UPDATES=Nach Aktualisierungen &suchen
MENU_MANAGE_APPS_GET_MORE_APPS=&Weitere Anwendungen...
MENU_MANAGE_APPS_GET_MORE_APPS_BY_CATEGORY=Nach &Kategorie
MENU_MANAGE_APPS_GET_MORE_APPS_BY_TITLE=Nach &Titel
MENU_MANAGE_APPS_GET_MORE_APPS_NEW_APPS=&Neue Anwendungen
MENU_MANAGE_APPS_GET_MORE_APPS_RECENTLY_UPDATED=Aktualisierte An&wendungen
MENU_MANAGE_APPS_GET_MORE_APPS_MOST_POPULAR=&Beliebte Anwendungen
MENU_MANAGE_APPS_INSTALL_AN_APP=Anwendung manuell &installieren
MENU_BACKUP=&Dateien sichern
MENU_RESTORE=Aus Sicherung &wiederherstellen
MENU_OPTIONS_SMALL_FONTS=&Kleine Schriftarten
MENU_OPTIONS_LARGE_FONTS=&Große Schriftarten
MENU_OPTIONS_UPDATE=Nach Aktualisierungen &suchen
MENU_OPTIONS_ADD_APP=Programm &hinzufügen
MENU_OPTIONS_REMOVE_APP=Programm &entfernen
MENU_OPTIONS_REFRESH_ICONS=&Symbole neu laden
[ . . .]

They do it the way srbs mentioned. Yeah, it's a hell of a lot of variables, but it's not like you'd need to use them outside of menus.cfg, so they wouldn't need to be documented or anything. Plus, more importantly, it uses far less storage space. All 54 of PA's locale files equal just shy of 1MB (~959KB)

The other reason I don't like my first option is what srbs also mentioned. Instead of sifting through an entire menus.cfg for each and every language, you'd have an organized, easy to edit locale file to modify.

That's just my opinion. Maintaining support for several languages is pretty damn monotonous and tedious, so I think this might be the easiest and most efficient way to go about it.
And we could even combine it with option 3 to save users even more space. Basically, when they went to download a release, they would select the desired language(s). Then (not sure on the mechanics) a "package" could be assembled that included all of the base files, plus the selected locale files.
For an example of this, use the customizer on http://painterlypack.net

[EDIT]
BTW, as far as translations go, we've got Droid and that new guy Jose who could translate to Spanish, and my girlfriend knows Chinese (spanish too). I'm in the process of learning Japanese, so I might be able to do something there sometime down the line if someone doesn't beat me to it. Several members of Frogteam are German, so I'm sure they'd be happy to help. As far as getting more goes, there's always the option of putting up some wanted signs around the net :P

[joseomaker]

I can help you to translate it,i can C++ edit code,is not the big deal.

[ZeroKnight]

Nice to know you'll help translate. However, we need to first agree on a method of doing this. In the end, it will be up to quin, so before putting anything together, I'd recommend we wait until quin decides which method he'd like to use.

[srbs]

Fourth Way:
Write a template menus.cfg (menu_template.cfg) which will build (only on change) the official menus.cfg file based on the translation variables in Second.5.
This can always be done in C++ for File I/O.

[arand]

Assaultcube is also looking into translations: http://forum.cubers.net/thread-4072.html (currrent svn has quite a few bits and pieces), they're basically using the gettext preprocessor to translate both c++ and cubescript.

http://www.gnu.org/software/gettext/manual/gettext.html

What's needed is basically marking all "this is a string" with gettext("this is a string") in the code, and then hook gettext up to process the code at compile time.
For translators they get a separate file with text string to translate, generated from the marks in the code, which is replaced in during compile.
EDIT: A translation isn't hard-compiled into the code, it's just that the code looks at the LOCALE set on the machine it is run, and then the gettext calls loads the correct translation from .po files. :ENDEDIT
So most of the translations material will be contained in a separate instance, which is pulled in selectively, and hopefully it won't be an assemblage of copulation...


The code marking is tedious, but hopefully rather trivial, I'd be up for running through one share of it if this is the case.

Assaultcube doesn't seem to have hooked up the thing to the standard Makefile yet. But I found a translation implementation for an older version of Sauerbraten as well: http://xpisar.wz.cz/sauerbraten-i18n/ , which have the whole thing hooked up and working (with a czech translation) for both c++ and cubescript translations.
(That patch doesn't apply cleanly to any existing version of sauer, but with a bit of fiddling it works, I can provide a patch against vanlilla sauerbraten_2008_06_20_ctf_edition_linux.tar.bz2 + patch_2008_12_06_linux.tar.bz2 if you want to have a look).

This is one way to do it, and it seems to be one of the most popular ways to i18n/L10n. If we do want to dig into that.

I do not know how well this works on windows/mac, but I think that it's a simple matter of getting the Make process to pull in gettext sanely.

[sireus]

Assaultcube doesn't seem to have hooked up the thing to the standard Makefile yet.

It is in effect, and it works pretty well in fact, although currently the only translation available is German. gettext is quite nifty.
However, the much harder aspect of I18n, in AssaultCube at least, are fonts. Some languages (such as German) let you easily replace its special characters with normal ASCII ones. But for languages with a completely different alphabet, you need something more advanced, like UTF-8 font rendering.

[DroiD]

Half way done

[DroiD]

2/3 done

[TheLastProject]

Aren't we still deciding on how to implement it? You're going to be wasting a hell of a lot of time, you know? =/

[DroiD]

look... im trying to do a menu in options to change language...dunoo if it will save tho :/
and joseomaker u DONT need c++ to edit menus

EDIT: dunoo if im wrong or not...

and how do i make RE save language?

[ZeroKnight]

Droid, we haven't yet decided how we're going to implement translations for RE. While this can be done in Cubescript, there are solutions that are better done in the long run with C++. If you're doing your own thing for your own use or to share with others, cool, but it wont be official.

And what do you mean, make it save the language?