| Getting i18n setting from database [message #460975] |
Wed, 03 January 2007 05:25  |
Eclipse User |
|
|
|
Hi all,
We want to save our i18n setting of our RCP application in database
instead of properties file, but since there's no way to make extension
points defined in plugin.xml (actionsets etc) to retrieve i18n settings
from database, we have to maintain 2 sources of i18n (in plugin.properties
for each client + each plugin & in database).
By saving the setting in database we ease the maintenance because all
plugins from all clients can retrieve the same i18n settings from one
database.
We can also develop an editor to change the settings or add new settings
later.
Has anyone encountered the same problem ?
Any suggestions would be greatly appreciated.
Best Regards,
Setya
|
|
|
|
|
| Re: Getting i18n setting from database [message #461038 is a reply to message #461032] |
Thu, 04 January 2007 06:03  |
| Eclipse User |
|
|
|
> 1. When does this 'build process' occur, is it when I export my
> plugin through Export Wizard in the manifest editor?
If you're manually building it, yes. But realistically, you'll want to set up something like CruiseControl to do automated builds. Have a look at e.g. http://eclipsezilla.eclipsecon.org/show_bug.cgi?id=18 or the automated builds article on Eclipse.
Generally, the reason for running a build system automatically is so that you don't inherit any specific properties that are due to an individual developer's configuration.
> 2. How can I hook my own process to generate plugin.properties
> during build process ?
In any case, you can add your own code to the build -- you'll need to investigate the customTargets.xml and build.xml generated by the process, and add whatever you need in there. There's an Ant SQL task which may help (http://ant.apache.org/manual/CoreTasks/sql.html) although you'll have to decide what to do with formatting it into an appropriate properties file.
> 3. From your suggestions, does it mean I won't have
> plugin.properties ready during development until I go through
> build process ? If that's so how can I test my application with
> various i18n settings during development ?
There's three aspects to the translations:
1) Picking a key to use (e.g. com.foo.FileMenu)
2) Picking a default translation (e.g. File)
3) Generating translations for 'File' in other languages
You'll need to decide on at least 1) whilst developing your program, even if the other translations don't exist yet. As for the default translation, people often use English or their first language, and then supply translations for others at a later stage. If you don't want to do 2) at the same time as doing 1) then you could always use either the key itself (e.g. com.foo.FileMenu) or a known token (e.g. TO_TRANSLATE).
Realistically, I don't recommend the use of the database to generate the 1) or 2) steps above. You should have this compiled and checked in to your version control system; instead, use the database to generate the separate translation files for each language as you need them (and once you've done that, check the translated files in too).
Alex.
|
|
|
| Re: Getting i18n setting from database [message #461046 is a reply to message #461038] |
Thu, 04 January 2007 07:17 |
| Eclipse User |
|
|
|
Alex,
> There's three aspects to the translations:
> 1) Picking a key to use (e.g. com.foo.FileMenu)
> 2) Picking a default translation (e.g. File)
> 3) Generating translations for 'File' in other languages
> You'll need to decide on at least 1) whilst developing your program, even if
the other translations don't exist yet. As for the default translation, people
often use English or their first language, and then supply translations for
others at a later stage. If you don't want to do 2) at the same time as doing
1) then you could always use either the key itself (e.g. com.foo.FileMenu) or
a known token (e.g. TO_TRANSLATE).
> Realistically, I don't recommend the use of the database to generate the 1)
or 2) steps above. You should have this compiled and checked in to your
version control system; instead, use the database to generate the separate
translation files for each language as you need them (and once you've done
that, check the translated files in too).
Thank you very much for your advice & links.
On the client side of our application (GUI) we often need to display
messages that come from the server side (EJB).
In this situation we have to options :
1. Have the server return the translated messages which means we have to
maintain the translation in client & server.
2. Have the server return only the message key and let the client
translate the message through the key so we only have to maintain the
translation at the client, but still we have to maintain the key at both
sides.
Which approach is the best ?
Regards,
Setya
|
|
|
|
| Re: Getting i18n setting from database [message #461108 is a reply to message #461069] |
Thu, 04 January 2007 22:51 |
| Eclipse User |
|
|
|
Alex Blewitt wrote:
> You probably need to separate out the messages that are displayed
intrinsically to the client (e.g. menu items etc.) from those that are
returned by the server.
> I'm surprised that your server sends back any translated messages though;
usually, you'd expect for some kind of code to be returned that could be
appropriately understood by the client. For example, HTTP's 404 code is sent
back from the server to indicate a missing resource, and then translated by
every client into Not Found (or something similar). Why can't you do the same
here? It would seem reasonable in this case to return the message using the
same message key as the translations that you're maintaining on the client,
and in addition, will avoid problems in the future where the NL setting for
the server is different from the client.
It's because unlike UI messages (menu items etc.), messages from server
mostly contain business meanings/terms (result of validations etc.) about
which the client side knows nothing and the client's job is only to
display it. So to me it seems awkward to maintain the translation of those
messages on the client side.
But I definitely will consider your approach.
Thanks and regards,
Setya
|
|
|
Powered by
FUDForum. Page generated in 0.02945 seconds
Home