[jbosstools-dev] Internationalising JBoss Tools

[Sean Flanigan]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 551 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20081023/04577c30/attachment.bin