I am thinking of tackling Internationalization. It will be a big job, but I think it is a good idea that we start developing a framework to implement internationalization asap. The actual conversion of VASSAL components to use the Internationalization framework will take the longest time, but it will not require a high level of VASSAL knowledge, so programmers with a lower level of VASSAL skills will be able to pitch in.
Here are some of my initial thoughts. Robust discussion required please! 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. 2. VASSAL IZ information should be stored outside of VASSAL itself, in text property files that can be individually downloaded and 'activated'. 3. VASSAL IZ information will be maintained using a special tool to allow people to easily view/create/modify VASSAL IZ property files. The list of Strings that need to be translated will be created automically by the VASSAL, based on the programmers use of the correct constructs. 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. 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 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 >*********** REPLY SEPARATOR *********** > >On 27/02/2007 at 1:02 PM Rodney Kinney wrote: >> I do think a standard way to do internationalization would be >> a very good and welcome addition to VASSAL. > >Agreed. VASSAL has quite a few international users. This is on the >roadmap, though not planned for the upcoming v3.0. > >rk ____________________________________________________________ Brent Easton Analyst/Programmer University of Western Sydney Email: [EMAIL PROTECTED]
