Hi All
As we are working with i18n for a while there are some conceptual questions arising. I would like to hear from others how they do it.
Situation: Application with a couple of modules (each having i18n)
-
As one can assign to each module (solution) a separate i18n table (in solution settings), under what conditions are you using that?
-
How do you handle the consistency problem, for example there exists througout the (whole application) the Cancel button. Do you add that in each module in a separate i18n table?
-
Are there rules when to define an element as module specific and when to define it as common element?
-
Currently we use the default messages table (for all modules). In this table are also the Servoy messages stored. How do they get updated? Should this table only be used for Servoy messages? Should always a separate table for the application i18n message be created?
Best regards, Robert
Our rules (for the moment) are defined in a way to achieve (in our view .-) the optimum between separation (add and remove modules from the application) and consistency, i. e. same element has same name. As there are many elements as tabs, buttons as well as labels and column titles, for example, it’s not so easy to get a good compromise.
May be others have found THE solution?
Our rules are:
-
We use the default messages table (though wonder how the Servoy message containe therin will be updated?)
-
We use the same table for all modules (incl. main)
-
if an element (object) is commonly used by many modules, we define it only once, e. g. Cancel button or labels or column header (in table view) occuring in many modules. This is assigned to our basic (core) module which is loaded by all modules.
-
If a element (object) is specific to a module, it’s i18n message is assigned to this module only.
-
We use a filter scheme to get messages accessible (grouped) in the i18n editor as follows:
General syntax: ...[].
Examples: hades.bas.btn.cancel → cancel button (commonly defined in core module)
hades.per.col.ccReceiver → table view column defined for person module only
hades.per.dialog.title.coAddresseCannotBeChanged → dialog title
hades.per.dialog.msg.coAddresseCannotBeChanged → dialog message
This last 2 use the optional subtype, i. e. title or msg.
Feedback welcome ![:-)]( "Smile")
Hi Robert,
We had pretty much the same thoughts than you (for the same reasons). But decided to go for another structure in order to keep further translations [addition of a new language] as easy as possible.
Our main goal is to avoid to translate things more than once, so we choose the dictionary paradigm for our i18n base, for the same reasons, we keep the default name for the message table, and use it as a table of our main database.
Our structure is:
prefix[.deprecator].word/concept[language specificity][.postfix]
Where:
prefix: only here to discriminate from servoy’s own i18n keys or others
.deprecator: used as commoditie to discriminate less or rarely frequently used sentences
.word/concept: dictionnary entry as single word or concept or up to three capitilized words (InvoiceCustomer, InvoiceSupplier)
language specificity: sometimes, one word may have several translations depending on language (SnowInuitDeep, SnowInuitWet, for instance)
.postfix: short, long or help form for word/concept
We choose english as reference language as it is obviously the most common language for programmers.
This is another view, hope it can help you choose.
Per solution, only 1 i18n table is loaded, which is the i18n table that is specified in the main solution.
Servoy system messages are not stored in a table, but in the code of Servoy.
Paul
pbakker:
Per solution, only 1 i18n table is loaded, which is the i18n table that is specified in the main solution.
Servoy system messages are not stored in a table, but in the code of Servoy.
Therefore if you use different i18n tables per solution that are (also) loaded as modules in other solutions you will have a problem.
Only the main solution i18n table will be used.
So when using modules you should use one central i18n table.
Hi Paul
So one should only specify one table in the main module (solution) as the i18n table and not specify any table name in the other modules? Or do I have to specify the same table (name) in each module?
In my i18n editor there are Servoy messages which I was wondering how they get updated? See attached picture. When do this messages get updated?
Thanks and best regards, Robert
pbakker:
Per solution, only 1 i18n table is loaded, which is the i18n table that is specified in the main solution.
Servoy system messages are not stored in a table, but in the code of Servoy.
Paul
Thanks Robert, so I assume one should only specify the i18n table once in the main module and none in the (sub)modules?
Best regards, Robert
ROCLASI:
pbakker:
Per solution, only 1 i18n table is loaded, which is the i18n table that is specified in the main solution.
Servoy system messages are not stored in a table, but in the code of Servoy.
Therefore if you use different i18n tables per solution that are (also) loaded as modules in other solutions you will have a problem.
Only the main solution i18n table will be used.
So when using modules you should use one central i18n table.
Only the main solution needs to have the proper i18n table. i18n tables of included modules/solutions are disregarded.
If you do use any of the included solutions also as a standalone solution, offcourse, you need to add the i18n table there as well.
What do you mean with updating of the Servoy System messages?
Paul
Hi Olivier
Good to hear how you do it ![:-)]( "Smile")
I think I don’t fully understand what’s behind deprecator and word/concept, language specifity but I do see the idea a bit.
I fond the postfix a good idea to separate short and long forms of words (which is quite common), but I don’t understand why it stands at the end? You can’t use it then as a filter criteria. Or is there still the “real” word after the .postfiy in your structure?
Best regards, Robert
olivier melet:
Hi Robert,
We had pretty much the same thoughts than you (for the same reasons). But decided to go for another structure in order to keep further translations [addition of a new language] as easy as possible.
Our main goal is to avoid to translate things more than once, so we choose the dictionary paradigm for our i18n base, for the same reasons, we keep the default name for the message table, and use it as a table of our main database.
Our structure is:
prefix[.deprecator].word/concept[language specificity][.postfix]
Where:
prefix: only here to discriminate from servoy’s own i18n keys or others
.deprecator: used as commoditie to discriminate less or rarely frequently used sentences
.word/concept: dictionnary entry as single word or concept or up to three capitilized words (InvoiceCustomer, InvoiceSupplier)
language specificity: sometimes, one word may have several translations depending on language (SnowInuitDeep, SnowInuitWet, for instance)
.postfix: short, long or help form for word/concept
We choose english as reference language as it is obviously the most common language for programmers.
This is another view, hope it can help you choose.
Paul
Thanks for giving more details!
By updating of the Servoy messages I mean:
There are message starting with servoy.xxx (or OptionPane.xxx) which are obviously from Servoy. I assume there are completed or updated from time to time as the Developer reaches new versions. So how are these messages updated? I do not assume they never get updated any more?
The reason I ask is because of the dangerous behaviour of the i18n editor (when sorting the 2nd column in the editor, the selected row jumps randomly to another row when pressing the delete button and deletes another row - I made already a case for that) we are not sure if we did accidentally delete one of the Servoy message(s).
Best regards, Robert
pbakker:
Only the main solution needs to have the proper i18n table. i18n tables of included modules/solutions are disregarded.
If you do use any of the included solutions also as a standalone solution, offcourse, you need to add the i18n table there as well.
What do you mean with updating of the Servoy System messages?
Paul
As I said before, the Servoy System Messages are not stored in the i18n table you set, they come from the Servoy code.
As soon as you reopen your solution after deleting them, they will be back again ![:)]( "Smile")
Ahh, so you are saying they are only displayed in the i18n editor but stored internally?
Regards, Robert
pbakker:
As I said before, the Servoy System Messages are not stored in the i18n table you set, they come from the Servoy code.
As soon as you reopen your solution after deleting them, they will be back again ![:)]( "Smile")
