In defense of the idea to have a separate package, I think it is a good idea to have a clear separation of the 2 areas. the code and the i18n text.
Your translators should not be assumed to be programmers, but if you could get them commit notices to the i18n master file (Or whatever it is called) then they know that they have something new to translate. On 3/2/07, David Stanaway <[EMAIL PROTECTED]> wrote: > > The tricky bit is when you make layout assumptions based on how the (en) > text looks, and when that get displayed in another perhaps more verbose in > some instances locale, things get cut off, or distorted. > Oh, that is aside from keeping the translations synced... > > On 3/2/07, Rodney Kinney <[EMAIL PROTECTED]> wrote: > > > > Never one to shirk from a challenge, Brent takes the i18n bull by the > > horns: > > > > 1. There will be two separate (though no doubt related) > > internationalization > > > (How 'bout we call that IZ) systems - One for translating VASSAL > > itself and > > > one for translating modules. > > > > Agree. > > > > 2. VASSAL IZ information should be stored outside of VASSAL itself, in > > text > > > property files that can be individually downloaded and 'activated'. > > > > Disagree. The VASSAL i18n (using the standard abbrev) info should be > > part > > of the software release. It's the translation of the menu/button text, > > so > > it's pretty closely tied to the code. Standard practice is to release > > those > > resource bundles together with the software and to use the locale of the > > user's machine to choose between them. > > > > 4. Module IZ information should be stored outside of the module, as an > > > Extension, or Extension like file that can be downloaded individually > > and > > > dropped into the Extension (or Language?) folder to become available. > > If > > > there are multiple language files, then pop up and ask which one to > > use. > > > > Agree. The module designer defines the text strings and the software > > should > > give them each a tag automatically (probably by hooking into > > StringConfigurer). Other users can use VASSAL to create an extension > > that > > translates the module into a particular language. > > > > 5. Module IZ information will be maintained within the module editor. I > > am > > > thinking we add a small language button at the end of every String > > input > > > field that will pop a little language window where you can type in > > > translations > > > > It would be ideal if a module could be translated without the module > > designer having to set anything up. I'd like to see a translation tool > > inside the VASSAL editor that showed the user what text strings are > > defined > > for the module (these would be determined automatically and have a > > pointer > > back to where they're used) and prompted the translator to enter his > > translation for whatever language he's building an extension for. > > > > 6. My feeling is we tackle Module IZ first, making it easy to translate > > > modules (i.e. what the user sees), while we continue to work on VASSAL > > IZ > > > > Agree. > > > > Go Brent! > > > > rk > > > > [Non-text portions of this message have been removed] > > > > > > > > [Non-text portions of this message have been removed]
