On Feb 27, 2007, at 8:43 AM, Tim Byrne wrote:
> Hi.
>
> I created a system to recreate modules in multiple languages. I
> plan on
> sharing this system with module developers.
>
> Basically the system extracts the buildFile, translates phrases
> that need
> translation, and creates a new module with the new buildFile. This
> process works great except for one problem.
>
> The problem I have is, if I change the name of the module (for example
> changing the name from "Module" to "Module(Espanol)") the module is no
> longer valid. I've determined that the validation happens with the
> "info"
> file embedded in the module.
>
> Can someone shed some light on the format of this file, so I can
> have my
> utility recreate/modify it as needed?
>
> I need to change the module name because there are elements of the
> modules
> that will be incompatible when playing with others. For example,
> if the
> names of the Sides are different in the two modules.
Sounds like a good effort.
I wonder if it would be easy to modify your system to generate something
more in line with the standard Java procedure for internationalizing
code,
namely the use of resource files for string constants.
Doing this may (most likely will?) require some additional support in
the
construction tool interface to Vassal. I've seen some other software
systems
(Stanford University's Protégé ontology editor comes to mind) which
use an
editor widget for strings which is actually a two-column table where the
second column is used to specify the language being used. Perhaps
something
like that could be used for module editing, so that one could have
something
like the following:
Value Lang Country
$piece moved to $new_location en US
$piece bewegt sich nach $new_location de DE
$piece va à $new_location fr FR
(Sorry if the other language examples aren't idiomatic....)
The values would then need to be stored in separate resource
files based on language. The references in those files would
need to have user or program-generated keys for reference.
It is a bit more work up-front for module designers, but having the
basic
tool support in place could make it a bit easier. User-generated keys
make things a bit simpler for translation, since they give a clue as to
the intended meaning:
MovementMessage = $piece moved to $new_location
is clearer than
StringValue_487 = $piece moved to $new_location
but the latter wouldn't be completely out-of-the-question, especially
since it would reduce the workload on the initial module designer.
Reference: Java internationalization tutorial
http://java.sun.com/docs/books/tutorial/i18n/index.html
Of course, this doesn't address the issue of text appearing in images
or on the map, so things like "Moved" marks that are Gifs would still
need a solution like Tim's....
