Can not start importing message bundles

[BiGuP]

Hello,

I evaluating Tonguetied, and the idea and architecture looks very
promising. But If followed the documentation : created the FR
language, the France country, but when i want to import a java
properties file 'messages.properties' I get the following Warning I
can't understand :

A problem occurred during import. See the recommended fix below for
more details. Once the problem has been fixed, try again.

The bundle name is not known to the system.
Check the name of the bundle exists in the bundle list.


I created a bundle named messages.properties but it does not solve the
problem.

Can you help me ?

Thanks.
Laurent.

[Ben Sion]

Hi Laurent,

I think my documentation is a bit poor. I will fix that up. The import fails because there is no resource bundle with a resource name equal to "messages". When creating bundles, you do NOT need to include the suffix as TongueTied can import and export to many different formats like .Net resources and Java properties. So for instance, you could create a messages.resx and a messages.properties and TongueTied will interpret the appropriate file suffix.

In short, to fix your problem please set your bundle to the following:

Name: messages   // I am assuming that the name is the same as the resource name but it can be different if you like
Description: // as you like
Resource Name: messages // This is the important part for importing and exporting as this is the bundle name without the suffix

Please let me know if this fixes your problem. Also I would be keen to hear any feed back you have to improve the product.

cheers,
Ben

[BiGuP]

Hello,

I was in vacation and I did not see the answer. Thanks for the help,
this is working now, and I can try using TongueTied.

The project I'm working on is quite huge regarding translation, and
for now I did not find any good tools (even commercial) for easily
translate and allow remote access for translaters to work. Tongue Tied
look very promising regarding these features, but it's difficult to
use it for me now :

The main problem for me is that, naming the bundle with the same name
of the properties file is a complicated for me because all my
translation files are named "messages.properties" or
"plugin.properties" but located in differents packages. In fact it's
an Eclipse based RCP application, so it's plugin based. All my
translations are stored in the plugins directory, and have the same
name.

Basically what i need to do to translate my RCP app is to :

1) import all the "messages.properties" in Tongue Tied from a source
code repository
2) translate the strings
2) export the translated files to the good plugin directories /
packages
3) commit to the source code repository

Clearly the fetching/commit from the source code repository is not
TongueTied's job. But how can I manage a "project" with Tongue Tied ?
There is no relation between the translation file, and how / where it
will be exported. Since all theses translation files have the same
name in my project (and I can't have bundle with same names in TT),
the only option in TongueTied is to renames all the
"messages.properties" to "some_directory_message.properties" and
script the TT's import/export to put the files back in the good
directories.

Do you have plans to better manage a project in TT ? I may see few
solutions :
1) Have the whole source code / message bundles directory tree on the
file system, an tell TT to work on these files, and the export will
generate the translated files in the same directory than the source
message bundle.
2) Allow to store a path in the message bundle description, so the
whole directory tree is created on when the file is exported.
3) allow to execute a script on each export

For the user side, TT lacks few features (or I missed them) to ease
the translation process :
- Define a main language for the user, so when he wants to translate a
string, his country/language is already selected by default for a new
translation.
- Propose the user to translated only untranslated strings, or verify
only unverified strings.
- Allow to enforce which user can tranlate which language (privileges)
- Add a next/previous keyword when translating a keyword.

These are just ideas and remarks, TT could be very nice in the
future !
Thanks.

Laurent.

[Ben]

Hi Laurent,

My apologies for the late reply. Glad to hear that it is working for
you now.

With regards to your comments.

> Do you have plans to better manage a project in TT ? I may see few
> solutions :

I figured this was best managed via an ant task and I plan to create
one for remote use with the TongueTied server. A project could call
the task to do the export. Imagine something like this (I have not
fully thought through the details yet)

...
<export todir="..." url="http://hostname/tonguetied/export"
extract="true">
<bundle name="..."/>
<country code="..."/>
<languge code="..."/>
<user name="..." password="..."/>
</export>
...

Obviously I am missing some important details as I have not fully
thought this through, but this would be the general idea of how it
would work when I get around to implementing this feature.

I see your problem where an export file can have the same name but
different location. It was not a problem I had originally foreseen. As
quick fix to this I think adding new field to store the directory tree
location may be a good option. I will investigate this further in the
next few weeks.

I will also look at your other suggestions:

> - Define a main language for the user, so when he wants to translate a
> string, his country/language is already selected by default for a new
> translation.

Does the "New Keywords by Language" option in the Keywords tab not
suffice? Or are you talking about some sort of

> - Allow to enforce which user can tranlate which language (privileges)

I thought about this but decided against it for now as it would have
been quite complicated. I will probably look at this for version 2.

> - Add a next/previous keyword when translating a keyword.

Not sure I understand this, can you give me an example.

thanks for all the valuable feed back. I appreciate it.

cheers,
Ben

[Ben Sion]

Hi Laurent,

One more thing I forgot to mention. After you have done your initial import of your resources into v1.2.1 (and below) if you change the resource name of the Bundle to "/<some>/<dir>/messages" then when you export the directory structure will be created for you. However, the importing feature does not currently support directories. I will add this in an up coming release. However this should ease your pain for exporting.

cheers,
Ben