JBoss Tools .pot files checked in; careful when renaming .properties!
by Sean Flanigan
G'day all,
I finally bit the bullet and put in a somewhat kludgy workaround for the
fact that properties files are not kept in the same directory under each
plugin, but all over the place (src, src/main, resources, jbosscore,
...). I can always take out the workaround when
https://jira.jboss.org/jira/browse/JBIDE-2972 is resolved.
With the workaround, the pot filenames should be fairly stable, so I've
checked in the converted pot files under i18n/po.
I really, really tried to avoid checking in generated files like pot
files. However, keeping pot files in the source tree seems to be a
universal convention for gettext projects, and corresponding pot and po
files are usually kept in the repository together. This enables
(non-programmer) translators to merge new strings for translation just
by checking out the po directory, without having to run xgettext (or
Ant-Gettext, in this case) against the entire codebase themselves.
Based on feedback from the L10n team, I have also changed the filename
mapping used when converting from .properties to .pot files. The pot
filename now eliminates segments like "src", "src/main", "resources",
"jbosscore", etc which are very likely to change over time. I have also
flattened the remaining directory hierarchy.
I think this retais enough of the original path to prevent name
collisions, but shortens it enough to be more changeproof and easier for
translators to work with.
With the new mapping, the names of source directories can be refactored
without affecting the .pots and thus invalidating translations. For
instance, changing myplugin/src/**/*.properties to
myplugin/resources/**/*.properties is perfectly safe. But changing the
name of a module, a plugin or a .properties file (or its package) will!
(See the end of this email.)
Thus the property file org/hibernate/console/ConsoleMessages.properties
in the plugin org.hibernate.eclipse (module hibernatetools) is mapped to:
i18n/po/hibernatetools/org.hibernate.eclipse-org.hibernate.console.ConsoleMessages/
org.hibernate.console.ConsoleMessages.pot
The po/pot files are still grouped into modules (for managability), and
we keep track of the plugin id and the resource path (ie the path used
at runtime to load the resource). The resource path is used again for
the filename within the directory, partly to make it easier to find (eg
in Eclipse, press Ctrl-Shift-R, the enter *ConsoleMessages or other
wildcard).
In accordance with the Gettext tools' default conventions, po files will
be kept in the same directory, but named ${locale}.po. So the above
directory will look like this when translated:
i18n/po/hibernatetools/org.hibernate.eclipse-org.hibernate.console.ConsoleMessages/
de_DE.po
es_ES.po
fr_FR.po
org.hibernate.console.ConsoleMessages.pot
pt_BR.po
zh_CN.po
Please be careful:
1. when renaming modules, plugins, .properties files, or packages which
contain .properties files, or
2. when moving plugins to a different module.
Any of these changes will prevent existing translations (when we have
some) from being picked up, unless the affected po directories and files
are manually renamed to suit. By me, probably. But feel free to rename
the affected po directories/files if you feel confident to!
I'm certainly not saying "don't rename things", but please try to go
easy on me! Thanks!
Regards,
Sean.
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat
16 years
Upgrade JBoss Tools build drivers
by Max Rydahl Andersen
Hi,
Eclipse WTP 3.0.3 is out and have a good couple of issues fixed which are
relevant for us.
We should start using this ASAP so QA can give it a good whirl.
Denis/Nick - you got info on how to set that up ?
On that note, WTP still has a couple of big issues that won't be fixed
before 3.0.4
which is targeted for February...this might influence our GA date.
--
/max
16 years
new_and_noteworthy for CR1
by Max Rydahl Andersen
Hi,
It is it that time again - tagging jiras in the upcoming release with new
and noteworthy for the CR release.
We got 9 issues marked in CR1 as new and noteworthy so we are already gone
more tags than the last time,
but I'm pretty sure we got more than 9 out of until now 347 issues fixed
for this CR1.
For those who have forgotten how easy it is take a look at
http://screencast.com/t/V4BZcUcq
that shows how to do this in the jira search window directly.
--
/max
16 years
Re: The new "i18n" directory in jbosstools
by Sean Flanigan
You can install, but do you get categories? I just tried using that
site from Eclipse 3.4.1 on Linux, and everything was under the
Uncategorized category. According to the site.xml, xulrunner should be
in the category "Mozilla Libraries", and everything else should be in
"JBossTools Development Release: 3.0.0.CR1-N200811201326".
Nick Boldt wrote:
> Hmm. I had no problem installing using p2 (Eclipse 3.4.1) from this
> site, which includes both a site.xml (Eclipse 3.3 update site) and
> content.jar/artifacts.jar (Eclipse 3.4 / p2 metadata):
>
> http://download.jboss.org/jbosstools/updates/nightly/trunk/
>
> Also no issues installing from a locally-built version, for that matter.
>
> Nick
>
> Sean Flanigan wrote:
>> Sean Flanigan wrote:
>>
>>> Max Rydahl Andersen wrote:
>>>
>>>>> I think adding P2 metadata to the repo is supposed to help:
>>>>> http://wiki.eclipse.org/Equinox_p2_Metadata_Generator . I might have to
>>>>> look at generating P2 metadata for the langpacks' site.xml.
>>>>>
>>>> we need to look into the same for our update site in general.
>>>>
>>> It turned out to be really straightforward, unless I'm not doing it
>>> right. Have a look at the p2 task in
>>> http://anonsvn.jboss.org/repos/jbosstools/trunk/i18n/build.xml
>>>
>>> The "hard" part was wrapping each argument in <arg> tags (and knowing
>>> that it's a good idea to turn off the splash screen (!) and enable
>>> console logging).
>>>
>>>
>> I knew it was too easy: https://bugs.eclipse.org/bugs/show_bug.cgi?id=240254
>>
>> As of Eclipse 3.4.1, you can have categories in your update site, or you
>> can have updates that finish within a human lifespan. Not both.
>>
>> In the case of langpacks, I think I'll keep the P2 metadata. I'll add a
>> note to the P2 JIRA: https://jira.jboss.org/jira/browse/JBIDE-2246.
>>
>>
>
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat
16 years, 1 month
The new "i18n" directory in jbosstools
by Sean Flanigan
Hi,
You might have noticed the new "i18n" directory. This contains the
beginnings of a new, optional, build step to generate language packs for
JBoss Tools. This is very much unfinished work, and quite a lot will
change, but I thought I should tell you what it is.
For now, it's safe to ignore the i18n directory, and this email, but if
you're interested, "ant all" in the i18n directory can:
1. Extract the English text from all the .properties files contained in
JBT's plugins, converting them to POT files. (These will be passed to
the Red Hat Localisation team for translation.)
2. Generate some English-based "translations" (en, qps, en_AA) for use
in testing. "en" is just the original English, which may or may not be
useful. The other two are identical pseudo-translations of the original
English. qps is a standards-compliant name for an artificial locale,
whereas en_AA fits in with the Babel project's pseudo-translation for
the Eclipse SDK.
3. Convert translated PO files (like the above-generated ones, or real
translations once they are checked in to i18n/po/${locale} into standard
Java .properties files under i18n/target/prop/${locale}. These prop
files are then packaged in language packs as plugin fragments and
features, along with an update-site site.xml. And for good measure, the
langpacks are packaged into monolithic zips too, one per locale.
If you point Eclipse's update manager at
file://${jbosstools-src}/i18n/target/jars/site.xml it's possible to
install some of the langpacks, eg org.hibernate.eclipse.feature. Others
fail with a dependency problem I haven't resolved yet. (Debugging hints
welcome!) And you will probably want to *disable all other update
sites*, because Eclipse takes forever to check dependencies otherwise...
(Again, any help welcomed!)
Note: to test Eclipse/JBDS with the en_AA locale, you can run the
eclipse executable with the option "-nl en_AA". Otherwise you won't see
the translated strings.
Warning: the i18n build file is extremely hideous, partly because it
overuses ant-contrib's features, but I'm working on that.
Sean.
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat
16 years, 1 month
Re: how to commit codes to JBDS?
by grid.qian
Hi guys,
I need to set the default values of wtp's web service server and runtime
in the eclipse config.ini file.
I add two lines in config.ini file
/instance/org.eclipse.jst.ws.consumption.ui/PREFERENCE_SERVER=org.eclipse.jst.server.generic.jboss42
/instance/org.eclipse.jst.ws.consumption.ui/PREFERENCE_RUNTIME=org.jboss.tools.ws.creation.jbossWebServiceRT
or
org.eclipse.jst.ws.consumption.ui/PREFERENCE_SERVER=org.eclipse.jst.server.generic.jboss42
org.eclipse.jst.ws.consumption.ui/PREFERENCE_RUNTIME=org.jboss.tools.ws.creation.jbossWebServiceRT
But these settings do not affect the results. I do not know how I should
write these lines.
Who can help me for this?
Grid
> The reason we wanted it in the jbds product configuration is that we
> must not do hardcoded
> overrides like this in JBoss Tools - it is not our decision to
> override the default setup in users existing Eclipse installation.
>
> Thus we can/should only do it in JBDS where we control the eclipse
> install.
> The reason I pointed to the product plugin is that it has a config.ini
> file in where you can set properties to override
> the behavior.
>
> I assume the following two lines of code:
>
> org.eclipse.jst.ws.internal.consumption.ui.plugin.WebServiceConsumptionUIPlugin.getInstance().getPluginPreferences().setDefault("PREFERENCE_SERVER",
> "org.eclipse.jst.server.generic.jboss42");
> +
> org.eclipse.jst.ws.internal.consumption.ui.plugin.WebServiceConsumptionUIPlugin.getInstance().getPluginPreferences().setDefault("PREFERENCE_RUNTIME",
> "org.jboss.tools.ws.creation.jbossWebServiceRT");
>
> Should be possible to do via config.ini or some other property file.
>
> If you don't know, then ask on Jboss tools dev where we got a few
> people that might know the answer.
>
> /max
>
>> Hi Max,
>> I have access to the link. It make me puzzled how to commit these
>> changes.
>> The steps are:
>> 1 check out the sources
>> svn checkout
>> https://svn.jboss.org/repos/devstudio/trunk/product/plugins/com.jboss.jbd...
>>
>> 2 commit my codes
>> svn commit -m "changes for JBDE-357"
>>
>> But in the link, there are not WS module codes. What I should commit?
>> only my changed codes or something else?
>> And what configuration file need I to change?
>>
>> So I have created a patch for this issue and uploaded it to the jira
>> for this issue.
>>
>> Thanks
>> Grid
>>
>>> I just checked and Grid.Qian does have access to that link.
>>> Are you using the correct login ?
>>>
>>> dennyxu did not have access for some reason so I went and added that
>>> too.
>>>
>>> Let me know how it goes and if you are uncertain if your changes are
>>> correct for
>>> the product configuration then just attach a patch to that issue and
>>> i'll look at it.
>>>
>>> /max
>>>
>>>> Hi guys,
>>>>
>>>> I fixed the bug JBDS-357,but I do not know where I should commit my
>>>> codes?
>>>> Denny give me a link:
>>>> https://svn.jboss.org/repos/devstudio/trunk/product/plugins/com.jboss.jbd...
>>>> But there are not codes in the link.
>>>>
>>>> Grid
>>>
>>>
>>>
>>
>
>
>
16 years, 1 month
