I18N management tool?

[unomystEz]

Hi all,

I'm sure some of you that have worked on i18n have had the same
problem I'm having at one point at least. I've decided to enable
japanese and french in my swing application and have a few questions
regarding keeping it managable. My swing app is relatively large now
and includes a lot of text, not like some apps that just need to
externalize 100 or so strings, my current properties file has over 500
entries now.

1. Entries are updated

I thought of putting revisions at the end of each key. ie:

WelcomeScreen.title.24 = Welcome to the lemonade stand app

so that if it were changed, you would automatically know if the other
languages are not up to date.

Right now, we move the updated entries to the bottom and put a comment
in front of them telling the others to update it.

2. Entries are deleted

Code is sometimes deleted that use entries in the properties files
and the keys are left in there... We haven't found any way to really
manage this except I was thinking of using unix tools like sed and awk
to compare the source against the properties files, I'm sure there is a
good tool out there to show missing entries and unused ones though.

3. Entries are added

When we add entries they usually only get added to the english file,
and the way we see if it's missing from the foreign language files is
to run the app in the other langs and see what keys it couldn't find
(our ResourceBundle will print a stack trace of unfound keys).

 

[PofN]

Hi all,

I'm sure some of you that have worked on i18n have had the same
problem I'm having at one point at least. I've decided to enable
japanese and french in my swing application and have a few questions
regarding keeping it managable. My swing app is relatively large now
and includes a lot of text, not like some apps that just need to
externalize 100 or so strings, my current properties file has over 500
entries now.

1. Entries are updated

I thought of putting revisions at the end of each key. ie:

WelcomeScreen.title.24 = Welcome to the lemonade stand app

so that if it were changed, you would automatically know if the other
languages are not up to date.

Right now, we move the updated entries to the bottom and put a comment
in front of them telling the others to update it.

Use your version control system to monitor file changes. Add a check-in
trigger to identify changed values. Generate a todo-task in your
progress tracking tool, telling you which values in the other bundles
need updating.

If your system can't do it, update to a non-toy system. If you work
without any version control system, consider a career change.

2. Entries are deleted

Code is sometimes deleted that use entries in the properties files
and the keys are left in there... We haven't found any way to really
manage this except I was thinking of using unix tools like sed and awk
to compare the source against the properties files, I'm sure there is a
good tool out there to show missing entries and unused ones though.

Sound's like a plan. A check-in trigger might be impractical for
monitoring this kind of change.

3. Entries are added

When we add entries they usually only get added to the english file,
and the way we see if it's missing from the foreign language files is
to run the app in the other langs and see what keys it couldn't find
(our ResourceBundle will print a stack trace of unfound keys).

Use your version control system. Add a check-in trigger to check the
key names in the file against the key names in every other resource
bundle. If the keys are not identical, refuse the check-in or generate
a todo-task in your progress tracking software.

PofN

 

[unomystEz]

Use your version control system to monitor file changes. Add a check-in
trigger to identify changed values. Generate a todo-task in your
progress tracking tool, telling you which values in the other bundles
need updating.

If your system can't do it, update to a non-toy system. If you work
without any version control system, consider a career change.


Sound's like a plan. A check-in trigger might be impractical for
monitoring this kind of change.


Use your version control system. Add a check-in trigger to check the
key names in the file against the key names in every other resource
bundle. If the keys are not identical, refuse the check-in or generate
a todo-task in your progress tracking software.

PofN

Hi PofN,

Thanks for your reply. We use CVS as our version control system.
One guy suggested that we add a version to each properties file and
basically do a diff between versions to see what's changed. I think
it's a good approach. I'm not sure how check-in triggers can be setup
with CVS but I will look around. I guess the programmers making
changes to the english version of the properties files need to start
tracking the changes and updating the issues system.

thanks

 

[Richard Wheeldon]

1. Entries are updated

If you're like me, translation updates will be done in a batch for a
given language, depending on release schedules, customers and other
annoying things. Simply take a diff of the English properties file since
the last French/Japanese/whatever translation.

2. Entries are deleted

This is a pita, but can largely be ignored. The best I've found is to
mark each properties entry in the form ClassName.property. At least this
way, you can easily check for values where the entire class has disappeared.

3. Entries are added

checkstyle will track missing translation key entries (amongst many
other uses),

Richard

 

[John O]

When we add entries they usually only get added to the english file,
and the way we see if it's missing from the foreign language files is
to run the app in the other langs and see what keys it couldn't find
(our ResourceBundle will print a stack trace of unfound keys).

However, the app does find the "default" resources with the new keys, right?

Regards,
John O'Conner

 

[unomystEz]

Yes it does return values from the "default" resource if it doesn't
find it in the "prefferred" resource.

After much thought and going through the replies, we decided that
perhaps the best method is to:

put a revision number in the english (since it's our native language)
file that is maintained by our CVS server via CVS tags.

and just do property diffs (not affected by property order, etc..)
between english revisions and give them to the translators.

thanks to all for their thoughts