RE: [Flightgear-devel] Internationalizing FlightGear.
Curt, > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Curtis L. > Olson > More work needs to be done, but you should be able to go into your > prefernces.xml file and specify the strings-de.xml file instead of the > strings-default.xml. Thanks, this works, while it's not quite logical. The line above it states so I'd never touch it ;-) Why not modify the next line to which seems more logical to me but, unfortunately, does not dp the job. Anyway, it's a good start. Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Internationalizing FlightGear.
Michael Basler writes: > > Okay, I made a German version of strings-en.xml which I called > strings-de.xml. I just submitted it to John asking him to install it under > /Translations in the base package. > > Questing: Is the lates CVS version of FlightGear able to use it and how > should this be done? More work needs to be done, but you should be able to go into your prefernces.xml file and specify the strings-de.xml file instead of the strings-default.xml. It would be nice to develop this further and also be able to do default keyboard bindings. Eric H. sent me a proposal so perhaps he'll get a chance to impliment it at some point. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Internationalizing FlightGear.
Okay, I made a German version of strings-en.xml which I called strings-de.xml. I just submitted it to John asking him to install it under /Translations in the base package. Questing: Is the lates CVS version of FlightGear able to use it and how should this be done? Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Curtis Olson wrote:
> The big thing that would need to be looked at is if we can include
> based on the contents of a property name, rather than just include
> some hard coded file name.
Like:
int main() {
char *sFile = getenv("FGFS_LANG");
char *LangStrings[] = {
#include sFile
}
...
}
:-)
Just trying to say that properties are intended to be dynamically variable, whereas
the "include" mechanism is processed at initial loading time, and I suspect it would
not be a good idea to hack it so that it can get the name from a property.
Still, a feature could (presumably) be implemented which dynamically loads in a file
of properties according to the current value of a filename property. This would be
over-kill for language selection, but would do the job and might be useful elsewhere.
For language selection, isn't there a way of specifying meta-variables in XML, which
might be the right thing to use?
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Andy Ross writes: > This is true, but it's handlable. The way the Gnome i18n stuff works, > the program is guaranteed to have american English text for > everything. These strings are often hardcoded, and are used as the > hash keys for translation lookups. So, in the worst case situation, a > user of an internationalized program with incomplete translation sees > the correct English text for the missing items. Since, sadly, this > happens all the time with translated programs anyway, it's not a huge > bug. :) > > Even better, since the translation tables are stored by themselves in > (reasonably) non-threatening text files, non-technical users can go in > there on their own, find the broken translation and fix it. > > The other big advantage to storing all the translations together > per-language is that it better optimizes the work done. Typically, > one person will do the translation for a single language, as Marcio > has done for Portuguese. If you make them sift through all the > translations for the the whole UI structure (which is probably split > across many files), their task is more difficult and technical. > > Or stated another way: if you store the translations per-language in a > single text file, the maintainer need only know English and the > translation language and be able to edit an XML file. If you store it > in the UI description too, then they need to understand the FlightGear > UI structure as well. This shrinks the number of translators > available, since they now have to be developers too. Ok, I have set up a first stab at this and will commit it to cvs. You will need to do a cvs update both of the FlightGear source code and the FlightGear base package. This just affects the menus right now, but could/should be extended to do options.xml as well. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Curtis L. Olson: > Well the difference is if you have one menu.xml for each languange, > then when someone adds a new option to the default menu.xml and > forgets to add it to all the other languange's menu.xml files you have > a problem and you are headed towards a big mess. This is true, but it's handlable. The way the Gnome i18n stuff works, the program is guaranteed to have american English text for everything. These strings are often hardcoded, and are used as the hash keys for translation lookups. So, in the worst case situation, a user of an internationalized program with incomplete translation sees the correct English text for the missing items. Since, sadly, this happens all the time with translated programs anyway, it's not a huge bug. :) Even better, since the translation tables are stored by themselves in (reasonably) non-threatening text files, non-technical users can go in there on their own, find the broken translation and fix it. The other big advantage to storing all the translations together per-language is that it better optimizes the work done. Typically, one person will do the translation for a single language, as Marcio has done for Portuguese. If you make them sift through all the translations for the the whole UI structure (which is probably split across many files), their task is more difficult and technical. Or stated another way: if you store the translations per-language in a single text file, the maintainer need only know English and the translation language and be able to edit an XML file. If you store it in the UI description too, then they need to understand the FlightGear UI structure as well. This shrinks the number of translators available, since they now have to be developers too. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Erik Hofman writes: > I don't get the point; > > 1. parts of the second xml file will *overwrite* previously read sections. > > 2. new parts added in the _first_ xml file will show up in English. > > This is what you are aiming for ins't it? Well, ok sure, it just seems less optimal and involves more duplication and thus more opportunity to introduce human error. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Curtis L. Olson wrote: > Erik Hofman writes: >>Curtis L. Olson wrote: >> >>>If we have one menu.xml file and one options.xml file, then one >>>".xml" file per language, then a person adding a menu >>>option or adding a command line option only needs to add it to the one >>>main xml file, and to the default translation file and it will then >>>show up automatically for all other languages (although in the default >>>language) and then it will stick out quite clearly so translaters can >>>fix up the new additions quickly. >> >> >>This is exactly what happens if you define load default file and load a >>language extension file containing only the translated parts. And then >>you have the option of loading two files, or just one file which >>includes the default in the first line. There is realy no difference >>between the two. > > Well the difference is if you have one menu.xml for each languange, > then when someone adds a new option to the default menu.xml and > forgets to add it to all the other languange's menu.xml files you have > a problem and you are headed towards a big mess. I don't get the point; 1. parts of the second xml file will *overwrite* previously read sections. 2. new parts added in the _first_ xml file will show up in English. This is what you are aiming for ins't it? Eri ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Erik Hofman writes: > Curtis L. Olson wrote: > > Erik, > > > > THe only thing I'm concerned about is if we have 10 different > > menu..xml files and then we want to do some work on the > > GUI, the person doing this needs to make the change in 10 different > > places, and in 9 languages they are unfamiliar with. > > > > If we have one menu.xml file and one options.xml file, then one > > ".xml" file per language, then a person adding a menu > > option or adding a command line option only needs to add it to the one > > main xml file, and to the default translation file and it will then > > show up automatically for all other languages (although in the default > > language) and then it will stick out quite clearly so translaters can > > fix up the new additions quickly. > > > This is exactly what happens if you define load default file and load a > language extension file containing only the translated parts. And then > you have the option of loading two files, or just one file which > includes the default in the first line. There is realy no difference > between the two. Well the difference is if you have one menu.xml for each languange, then when someone adds a new option to the default menu.xml and forgets to add it to all the other languange's menu.xml files you have a problem and you are headed towards a big mess. If you have one menu.xml file, then at least new additions will show up for people running other languages, the entries will just show up (most likely) in english. This will be a tip off that they need to go into their translations file and add an entry for the item that is coming up in english. Otherwise they won't even know something was added to the default menu.xml and they will all get out of sync (probably very quickly.) If we halt all development now and the menu.xml will never change in the future, then yes, the two approaches are pretty much equivalent. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Curtis L. Olson wrote: > Erik, > > THe only thing I'm concerned about is if we have 10 different > menu..xml files and then we want to do some work on the > GUI, the person doing this needs to make the change in 10 different > places, and in 9 languages they are unfamiliar with. > > If we have one menu.xml file and one options.xml file, then one > ".xml" file per language, then a person adding a menu > option or adding a command line option only needs to add it to the one > main xml file, and to the default translation file and it will then > show up automatically for all other languages (although in the default > language) and then it will stick out quite clearly so translaters can > fix up the new additions quickly. This is exactly what happens if you define load default file and load a language extension file containing only the translated parts. And then you have the option of loading two files, or just one file which includes the default in the first line. There is realy no difference between the two. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Internationalizing FlightGear.
Michael Basler writes: > >From a user's perspective, a clever solution might be having a menu entry > "Language" which defaults to English, but can be changed to French, > German... The selection would then select the proper xml files for diplaying > menu, messages etc. There are several programs having this, e.g. Ghostview > (Windows Postscript viewer front end based on Ghostscript) just to name an > example. For their technical documents, the major aircraft manufacturers use something called 'effectivity' -- every pageblock, task, step etc. can have an effectivity label like For all jets with Pratt and Whitney engines. or For serial numbers 200-230. When these are put in computer-readable form, the publishing system can filter out unneeded material to create a customized manual for each airline (if they don't have any MD80's with GE engines, don't include the sections on GE engines). Language filtering is just a special case of effectivity. XML already has a simplistic mechanism for this using the pre-defined xml:lang attribute: airport Flughaven aéroport cornfield Personally, I'm not entirely happy with this. The fact is that we probably want to filter properties based not only on natural language but on operating system, GPU, resolution, input devices, and even user preferences (i.e. high/low level of detail). A general-purpose effectivity mechanism could be useful, as long as it was easy to learn and support. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Frederic BOUVIER writes:
> Curtis L. Olson <[EMAIL PROTECTED]> wrote :
>
> > The strings-fr.xml file would look something like (according
> > to babelfish):
> >
> > Dossier
> > Economiser le vol
> > Vol de charge
> > Remise
>
> babelfish is very funny ;-)
"Economiser le vol" was the funniest ("fly cheap!") -- I think that is
the funniest posting we've ever had with FlightGear. Did Curt really
got them from Babelfish, or did he have someone from the French
department at his university help him make them up.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Internationalizing FlightGear.
Hi, >From a user's perspective, a clever solution might be having a menu entry "Language" which defaults to English, but can be changed to French, German... The selection would then select the proper xml files for diplaying menu, messages etc. There are several programs having this, e.g. Ghostview (Windows Postscript viewer front end based on Ghostscript) just to name an example. Would this be hard to realize in FlightGear? Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Curtis L. Olson <[EMAIL PROTECTED]> wrote : > The strings-fr.xml file would look something like (according > to babelfish): > > Dossier > Economiser le vol > Vol de charge > Remise babelfish is very funny ;-) Hopefully, someone already offered to help translating. Fichier Sauver le vol Ouvrir un vol Réinitialisation Anyway, I agree with you point. In the product I am managing in my company, we use IDENTIFIERS in the source code (here in a XML file) with a simple file name. At run-time, the file name is search in a set of include path that depends on the language tag. If IDENTIFIER can't be looked-up, the string "IDENTIFIER" is used, so we can see it is missing. I think it is also the spirit of GNU gettext but it uses plain english strings as identifiers. Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Internationalizing FlightGear.
Richard Bytheway writes: > Sounds sensible. > > Could the appropriate text..xml file be determined > automatically in a repeatable, portable way at runtime (with > optional override of course)? > Perhaps if were the country code, or at least derived > from it? > > Would this, or a similar scheme, also be suitable to localise the > keyboard bindings. For instance, on my UK keyboard the engine select > keys are shift-1, shift-', # and shift-4, ie engine two and three > selectors are way over on the right hand side of the keyboard, " > (double quote) and £ (GBP symbol) are shifted 2 and 3. > I imagine that non English keyboards are even worse. I bet if we could figure out the mechanism for doing text strings we could do something similar with key bindings. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
David Megginson writes: > Curtis L. Olson wrote: > > > Having given a very tiny bit of thought to 'internationalizing' > > flightgear I thought perhaps a first start would be to provide > > translated versions of menu.xml and options.xml > > I'm looking forward to the Minnesotan translation. Will it sound like > Prairie Home Companion, or Fargo? David, With the current property system, is it possible to do something like the following. In preferences.xml have an entry like: strings-fr.xml Then in menu.xml use a property value to specify the include file, something like: Then in menu.xml we could reference the strings property names (thus indirectly referencing the actual text) rather hard coding the text: /strings/file /strings/save-flight saveFlight /strings/load-flight loadFlight /strings/reset reInit The strings-fr.xml file would look something like (according to babelfish): Dossier Economiser le vol Vol de charge Remise The big thing that would need to be looked at is if we can include based on the contents of a property name, rather than just include some hard coded file name. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Erik, THe only thing I'm concerned about is if we have 10 different menu..xml files and then we want to do some work on the GUI, the person doing this needs to make the change in 10 different places, and in 9 languages they are unfamiliar with. If we have one menu.xml file and one options.xml file, then one ".xml" file per language, then a person adding a menu option or adding a command line option only needs to add it to the one main xml file, and to the default translation file and it will then show up automatically for all other languages (although in the default language) and then it will stick out quite clearly so translaters can fix up the new additions quickly. Regards, Curt. Erik Hofman writes: > Curtis L. Olson wrote: > > Having given a very tiny bit of thought to 'internationalizing' > > flightgear I thought perhaps a first start would be to provide > > translated versions of menu.xml and options.xml > > > > It would be nice to do this in a sensible organzied way so that when > > we add a menu option to the default menu, we don't have a logistical > > nightmare with maintaining the translated versions. > > > > Maybe something like: > > > > > > .xml> > > > > > > > >/langauge/menu/file-text > > > > /langauge/menu/save-file-text > > saveFlight > > > >. > >. > >. > > > > Then text.usa.xml (or whatever naming scheme we use) could look > > something like > > > > > > > > File > > Save File > > > > > > > > We could do something similar for the options.xml file. > > If I understand the properties load code well enough, it would be > enought to have a .xml file which gets loaded after the > default file, overriding everything defined in the language specific file. > > For example: > > menu.xml : > > > > File > > Save flight > saveFlight > > > ... > > menu.nl.xml would become: > > > > Bestand > > Vlucht opslaan > > > ... > > Now we just need a loader which determines the default language and > loads two files into one single root node. > > > > > The idea would then be that we first load in the 'default' > > translation, and then overwrite it with the local user specified > > translation. > > > > This way, if a new option is added to FlightGear, the system will have > > a default translation there and you don't see garbage or wierdness. > > We only have to maintain one menu.xml/options.xml file and one > > translations file per language. > > > > If an item is added to FlightGear and not translated, it will stick > > out like a sore thumb and the individual translaters can add that to > > their .xml file. > > This would countr for the above solution as well. > We must keep in minf that there will be extensions to the > menu.xml/options.xml files which don't affect the translation (scripting > for example), so it would be nice if translations only require small > language speciffic changes. > > > > > Does this sound reasonable? Can we pull this off (or something > > similar) with the property system? > > As far as I know, we could. > > Erik > > > > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Curtis L. Olson wrote: > Having given a very tiny bit of thought to 'internationalizing' > flightgear I thought perhaps a first start would be to provide > translated versions of menu.xml and options.xml I'm looking forward to the Minnesotan translation. Will it sound like Prairie Home Companion, or Fargo? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Hi Curtis, hi to all, When you'll be OK on the way to translate FlightGear, I could do the french translation. I'm OK for the way below, but I couldn't have a good advice, I'm not dev ;-) Bye, Fabien Curtis L. Olson wrote: > Having given a very tiny bit of thought to 'internationalizing' > flightgear I thought perhaps a first start would be to provide > translated versions of menu.xml and options.xml > > It would be nice to do this in a sensible organzied way so that when > we add a menu option to the default menu, we don't have a logistical > nightmare with maintaining the translated versions. > > Maybe something like: > > > .xml> > > Does this sound reasonable? Can we pull this off (or something > similar) with the property system? > > Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Curtis L. Olson wrote: > Having given a very tiny bit of thought to 'internationalizing' > flightgear I thought perhaps a first start would be to provide > translated versions of menu.xml and options.xml > > It would be nice to do this in a sensible organzied way so that when > we add a menu option to the default menu, we don't have a logistical > nightmare with maintaining the translated versions. > > Maybe something like: > > > .xml> > > > >/langauge/menu/file-text > > /langauge/menu/save-file-text > saveFlight > >. >. >. > > Then text.usa.xml (or whatever naming scheme we use) could look > something like > > > > File > Save File > > > > We could do something similar for the options.xml file. If I understand the properties load code well enough, it would be enought to have a .xml file which gets loaded after the default file, overriding everything defined in the language specific file. For example: menu.xml : File Save flight saveFlight ... menu.nl.xml would become: Bestand Vlucht opslaan ... Now we just need a loader which determines the default language and loads two files into one single root node. > > The idea would then be that we first load in the 'default' > translation, and then overwrite it with the local user specified > translation. > > This way, if a new option is added to FlightGear, the system will have > a default translation there and you don't see garbage or wierdness. > We only have to maintain one menu.xml/options.xml file and one > translations file per language. > > If an item is added to FlightGear and not translated, it will stick > out like a sore thumb and the individual translaters can add that to > their .xml file. This would countr for the above solution as well. We must keep in minf that there will be extensions to the menu.xml/options.xml files which don't affect the translation (scripting for example), so it would be nice if translations only require small language speciffic changes. > > Does this sound reasonable? Can we pull this off (or something > similar) with the property system? As far as I know, we could. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Internationalizing FlightGear.
Sounds sensible. Could the appropriate text..xml file be determined automatically in a repeatable, portable way at runtime (with optional override of course)? Perhaps if were the country code, or at least derived from it? Would this, or a similar scheme, also be suitable to localise the keyboard bindings. For instance, on my UK keyboard the engine select keys are shift-1, shift-', # and shift-4, ie engine two and three selectors are way over on the right hand side of the keyboard, " (double quote) and £ (GBP symbol) are shifted 2 and 3. I imagine that non English keyboards are even worse. Richard > -Original Message- > From: Curtis L. Olson [mailto:[EMAIL PROTECTED]] > Sent: 30 September 2002 8:46 pm > To: [EMAIL PROTECTED] > Subject: [Flightgear-devel] Internationalizing FlightGear. > > > Having given a very tiny bit of thought to 'internationalizing' > flightgear I thought perhaps a first start would be to provide > translated versions of menu.xml and options.xml > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
> Having given a very tiny bit of thought to 'internationalizing' > flightgear I thought perhaps a first start would be to provide > translated versions of menu.xml and options.xml > Well, I've just translated these files... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
