Re: [jbosstools-dev] Internationalising JBoss Tools
Max Rydahl Andersen wrote:
Hi,
I'm not so worried about size but if there at some point will be other
resources that needs translations i.e. images.
Yes; it's best to avoid this (eg by avoiding static text in images, and
drawing translated text over the top at runtime), but of course that's
not always possible.
(Better add that to the roadmap for jbosstools-i18n: include binary
resources in lang-packs.)
No, my worry is timing and that I don't think we should hold back
GA
releases
of JBoss Tools/JBDS just because l10n is not done yet. I think it makes
perfect sense to do the additional languages as language feature/fragment
packs
that users can download or optimally get via an updatesite.
Quite true.
Regarding getting us to use the same name for the properties then
I'm very
much for that; it makes translation and build scripts much more easy to
maintain.
Sean - could you create issues in jira (and patches if you can ;) for
those changes
you would like to see in our plugins to make translation easier ? Thanks.
Will do.
About project structure then let us *start* by having it in
trunk/localization/*
and have it mimic the structure of the module tree to have the proper
"splits" for
the feature packs.
That sounds like exactly what I wanted. (Except for spelling
localisation with a Z! ;-) But let me just check that I understand the
terminology:
These are "modules":
archives, as, birt, cache, common, core, ... vpe, ws
ie groups of features and plugins which share a theme/area?
I was already planning/hoping that the pot/po trees would reflect the
entire source tree under trunk, leading to filenames like these:
trunk/localization/pot/as/plugins/org.jboss.ide.eclipse.as.classpath.ui/src/org/jboss/ide/eclipse/as/classpath/ui/ClasspathUIMessages.pot
trunk/localization/po/qps/as/plugins/org.jboss.ide.eclipse.as.classpath.ui/src/org/jboss/ide/eclipse/as/classpath/ui/ClasspathUIMessages.po
By keeping the module names (and "src/"), it makes it easy to keep track
of the exact source of each file, and potentially put them back at
build-time.
At runtime the properties file needs to be available on the classpath as
`org/jboss/ide/eclipse/as/classpath/ui/ClasspathUIMessages_{locale}.properties`
by removing "{module}/plugins/" and "src/" from the pathname.
At the moment, the shell script jbosstools-frag.sh is responsible for
tweaking the pathnames when creating the fragment jars. Some of the
kludgiest parts of the script are the ad-hoc pathname tweaks. So the
more we can standardise the pathnames, the better!
But Max, why is it that you want the proper splits in the localization
project? Are you thinking of per-module lang-packs?
Let's get it started and get it concrete then we can readjust
the structure if needed. Sean, what do you think about that ?
That sounds good to me. I actually got jbosstools-frag.sh working with
the Ant tasks yesterday, so I'd be happy to check in the
"trunk/localization" project right now, if you like, before working to
replace jbosstools-frag.sh with more Ant.
Actually, there's one thing I should probably sort out before checking
in "localization". Localization's build.xml uses a few binary jars to
implement Ant tasks and their dependencies (ant-contrib, antlr,
ant-gettext, jgettext and openprops).
Ant-contrib and ANTLR, you've probably heard of. The other jars come
from our projects at <https://fedorahosted.org/tennera> (as soon as my
svndump is imported) and <https://fedorahosted.org/openprops>;.
How would you prefer to handle external dependencies like these?
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat
Attachments:
- signature.asc (application/pgp-signature — 551 bytes)