Module translation issues

TOPO’s testing of the module translation facilities has opened up a can of worms. I have found at least one and probably a series of potentially significant problems.

These problems have always been there, I think TOPO is the first person to try and get a complex module translated and working.

I suggest we don’t hold up 3.1, but aim to get the problems resolved in a point release.

B.

Joel,

I am just sidetracking this discussion over to this thread

Having raised these issues, I am not against the idea of a re-engineer.

The current module translation scheme was designed as a method of bolting translations to modules on with as little disruption to the existing Vassal structures as possible.

It seemed like a good idea at the time, but I am starting to get the (rather unpleasant) feeling that some core assumptions may have been flawed.

I am not against a re-engineering of the module translation system to be key-based as you suggest, as long as we can transparently convert existing modules.

As far as I know, the module translation facility is now being used for the first time, so now is a good time to address this.

B.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

My main concern here is that we fix things as soon as possible after we
discover they’re flawed, as that minimizes the problems we face in the long
run.

It seems like this works well for the app as a whole, so it’s the first thing
which occurred to me.

So long as we can read from existing modules what language they’re in,
then I don’t see why we couldn’t have a script which extracts the current
text to a properties file.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

That’s the first problem. We don’t actually know what language the module is written in. I had wanted to add a 'Base Language=XXXXXXX" attribute to the module metadata, but it never happened.

I’m actually not that worried about conversion, I’m sure we’ll be able to sort that out.

I’m thinking of the practicalities of supporting a change to key based module text. I remember looking at this when I started the i18n project. Generating and maintaining unique keys as component names change is a potential nightmare.

B.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

This may actually be just a problem with Decks not handling localized names properly.

The actual problem is that Decks create Global properties based on their name. The existing code is using the localized name to create the properties instead of the actual name.

I’m looking into this now, it may be just a few bug fixes to get the current system up and running as it is supposed to work.

B.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

We went around and around on this, as I remember. In fact, the current module translation scheme is key-based. The basic design questions are A) does the user supply the key names or does the system generate them? and B) is translation done dynamically at play time or during module build time?

For A) we chose to have the system generate the keys, which I think is the obvious right choice. (Making users come up with key names and string values for every single property of every single component in a module is heinous.)

For B) we chose to do it at module build time. That introduced some complexity to the module build logic, but I don’t think it’s the source of the bugs we’re discussing here. I actually think this choice was a big success from several points of view. First, it has introduced zero bugs on modules that have no translation. Second, it has allowed new components to be i18n-able right out of the box with no special coding required. It’s very easy to imagine the bugs we’d have if we’d had to go through every single property of every component, find the places where they’re used, and swap in i18n translations at every point.

rk

Post generated using Mail2Forum (mail2forum.com)

Thus spake Rodney Kinney:

I don’t understand what you mean by this.

Yes, those bugs would be easy to correct.

I would expect that we’d be getting translations from a method, not
implementing the translation logic everwhere it’s used.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

Why? That could be done by preventing componenents from being given names
already in used.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Turned out to be crosstalk between translated and untranslated module information.

Fixes are in swampwallaby-3.1@5165


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

Merged to 3.1@5166, trunk@5167.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

If we didn’t do the translation at module build time, then every component would have to wrap every use of every attribute in a call to Resources.getString(). These would be easy to forget and it’s a sure thing that new developers contributing new code would leave them out. As it is, we only have to call Resources.getString() if there’s a literal string in the code that needs to be translated, and Eclipse can automatically locate all possible places in the code where we might need to translate.

rk

Post generated using Mail2Forum (mail2forum.com)