Re: [jbosstools-dev] How to keep track of ResourceBundle keys?
Max Rydahl Andersen wrote:
My worry is that our build today is not exactly a piece of cake to
get
setup
BUT it at least run on all the platforms that we have developers on
(windows, mac and linux)
then I would be against something that would restrict that since going
forward
I would like to get the build made much much simpler than it is
today....at least
keep that hope alive.
If I were to change the build, (I think) it would only be to add
optional tasks, so it shouldn't affect most developers. But I think I
would prefer a separate i18n server anyway.
mkay - if you want to maintain a seperate build for it be my guest;
but what do you do when the properties files get updated by jboss tools
dev ... you would just nuke them or ?
I was hoping you wouldn't notice that hand-wave ;-), because I haven't
worked out what to do in the case of translation conflicts just yet.
Here goes some more thinking by writing...
Ideally, translations would flow in one direction only (thus eliminating
conflicts), but we would want the translations to be kept somewhere open...
The problem is that developers would prefer to modify translations in
the .properties files, but translators generally don't. Some
translators do their work in TMX, or XLIFF, but the Red Hat localisation
team generally uses GNU gettext formats (POT/PO).
I want to make developers' lives easy, but it's a balancing act, because
I don't want to make translators' lives hard either. That means you
don't want to force translators learn a new file format just to work on
a new project.
If we make the PO files the definitive translations, then developers
need to be able to (a) modify translations - that's fairly easy, PO
editors are far better than ResourceBundle editors and (b) test their
code with the latest translation. Which means they need to convert the
PO files into ResourceBundles.
And now we're back to needing file conversion as part of the build!
Hmm. Not great. It might work better the other way (.properties as
canonical), if the conversion tools are up to it (ie conflict handling).
This thinking by writing isn't getting me very far. I'll have to think
about it over the weekend.
I think the answer will lie in making sure it's developers who handle
svn conflict resolution, not translators or build/i18n servers. Along
with avoiding svn conflicts as much as possible, thanks to smart
conversion tools.
More to come...
Sean.
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat