| Getting i18n setting from database [message #460975] |
Wed, 03 January 2007 10:25  |
|
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 #461032 is a reply to message #460980] |
Thu, 04 January 2007 02:49  |
|
Thanks Alex for your response,
> 2) Storing the translations of the individual labels that are currently
stored in the various .properties files that are used by your application
Yes, this is exactly what I'm trying to achieve.
> What I'd recommend is that you have the translated entries stored in the
database for ease of storage/management, and then use that to automatically
generate the plugin.properties for each plugin as part of the build process.
> You would also be able to automatically extract these translations from your
DB to generate fragments, much like the RCP NL pack is distributed today.
> Using a build-time process to extract translations into appropriate
properties files is going to be a much more sensible suggestion than trying to
hack the Eclipse code to do lookups when the application starts.
Thanks, these are good ideas. Now my questions here :
1. When does this 'build process' occur, is it when I export my plugin
through Export Wizard in the manifest editor ?
2. How can I hook my own process to generate plugin.properties during
build process ?
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 ?
Thanks in advanced.
Regards,
Setya
|
|
|
| Re: Getting i18n setting from database [message #461038 is a reply to message #461032] |
Thu, 04 January 2007 11:03 |
 Alex Blewitt
Messages: 946
Registered: July 2009 |
Senior Member |
|
|
> 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 12:17 |
|
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] |
Fri, 05 January 2007 03:51 |
|
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.02619 seconds
] 
Search
Help
Register
Login
Home
