Hi,
I just noticed that i18n translations were lost in the following situation:
Computer A was adding translations for existing messages-keys in German
Computer B was adding new message keys in English and Dutch
Computer C was also adding new message keys in English and Dutch.
Several i18N messages were lost (mainly German translation from computer A).
Could there be some issue with the message-id?
All computers were adding labels from developer.
Perhaps developer A doesn’t see that another developer (B) was adding new records in the i18n table and previous translations were overwritten, maybe because the message-id sequence counter was stored locally?
Anyone has seen same issue?
Martin
martinh:
Perhaps developer A doesn’t see that another developer (B) was adding new records in the i18n table and previous translations were overwritten, maybe because the message-id sequence counter was stored locally?
You are right, if you have startAsTeamProvider=false and the pk of the i18n table is a Servoy sequence (that is managed locally in this case), there is a possibility for this to happen…
In general using the same DB servers/tables for multiple developers when startAsTeamProvider=false can result in such problems for Servoy sequence columns, as sequences are managed locally in this case, and not through the repository DB.
You could make that pk dbident - if it is managed by the database, then you should not have this problem.
Starting with Servoy 5 the i18ntable (while in developer) was replaced by text files that can be put under source control - so this problem is avoided in 5.
Hi Andrei,
I think you pointed to the right cause.
Our developers (in my example computer B and C) have startAsTeamProvider=false in the property settings and work on local PC
But the developer A had started a developer on the server and there the setting startAsTeamProvider was set to true, because developer A had started a Terminal Server session to our server.
So developer A was running with startAsTeamProvider=true and that probably has caused why those translations were lost.
To avoid happing this again, could it be an option to install an extra developer in another path, with startAsTeamProvider=false in the property file?
Martin
It can only be avoided if all developers have startAsTeamProvider set to true or if you change the pk column type to dbident.
Having startAsTeamProvider set to false on any of the developers using the same i18n table (with Servoy sequence pk) can lead to this problem.
As I am a fan of startAsTeamProvider set to false for developer ![:)]( "Smile")
, and you are working on different computers I think changing the i18n table’s pk column to a DB managed increment would be the best way to go. You’ll need to run some manual queries/db tools for that, but I think it’s for the best.