[ATTN] Changing messages with variable placeholders
all, in general, changing non-English messages in the code is forbidden, as these are pulled automatically from the translation management system (Zanata). HOWEVER: changing non-English messages in the code is *a must* in case not doing so will result in maven build failure. this can happen when changing the quantity of variable placeholders in localized messages. example: let's say that I have an English message: "xxx {0} yyy {1}" and the parallel non-English messages are: "aaa {0} bbb {1}", "ccc ddd {0} {1}", "{1} eee fff {0}", etc. If I am changing the English message to be: "xxx {0}" but leaving the parallel non-English messages as is: "aaa {0} bbb {1}", "ccc ddd {0} {1}", "eee {1} fff {0}", etc. now the messages for the same key in different locales have different amounts of variable placeholders in them. this would result in a mvn build error. ** so whenever changing the quantity of variable placeholders in an English message, you must change the parallel non-English messages to match the new variable placeholders quantity. ** in the example above: the "{1}" placeholder (that was removed from the English message) should be removed from the non-English messages, so that the updated non-English messages would be: "aaa {0} bbb", "ccc ddd {0}", "eee fff {0}", etc. you don't need to worry about the correctness of the non-English messages that you are changing; this will be taken care of in the translation cycle that will follow your patch. you just need to do the minimal changes necessary (remove placeholders / append placeholders) so that build errors will not occur. NOTE: this can be very easily missed, as this type of build error will occur only when building the project with non-English locales (e.g. with the "BUILD_LOCALES=1" parameter within the "make" command in a devel env). So please - pay extra attention when making this kind of messages changes; if in doubt - build with "BUILD_LOCALES=1" and/or ask. Let me know if you have any questions. Many thanks in advance. ---- Regards, Einav
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: devel@ovirt.org Sent: Thursday, September 11, 2014 4:04:23 PM Subject: [ovirt-devel] [ATTN] Changing messages with variable placeholders
all,
in general, changing non-English messages in the code is forbidden, as these are pulled automatically from the translation management system (Zanata).
HOWEVER: changing non-English messages in the code is *a must* in case not doing so will result in maven build failure.
this can happen when changing the quantity of variable placeholders in localized messages.
example:
let's say that I have an English message: "xxx {0} yyy {1}" and the parallel non-English messages are: "aaa {0} bbb {1}", "ccc ddd {0} {1}", "{1} eee fff {0}", etc.
If I am changing the English message to be: "xxx {0}" but leaving the parallel non-English messages as is: "aaa {0} bbb {1}", "ccc ddd {0} {1}", "eee {1} fff {0}", etc.
now the messages for the same key in different locales have different amounts of variable placeholders in them. this would result in a mvn build error.
** so whenever changing the quantity of variable placeholders in an English message, you must change the parallel non-English messages to match the new variable placeholders quantity. **
in the example above: the "{1}" placeholder (that was removed from the English message) should be removed from the non-English messages, so that the updated non-English messages would be: "aaa {0} bbb", "ccc ddd {0}", "eee fff {0}", etc.
you don't need to worry about the correctness of the non-English messages that you are changing; this will be taken care of in the translation cycle that will follow your patch. you just need to do the minimal changes necessary (remove placeholders / append placeholders) so that build errors will not occur.
NOTE: this can be very easily missed, as this type of build error will occur only when building the project with non-English locales (e.g. with the "BUILD_LOCALES=1" parameter within the "make" command in a devel env). So please - pay extra attention when making this kind of messages changes; if in doubt - build with "BUILD_LOCALES=1" and/or ask.
Let me know if you have any questions.
Many thanks in advance.
If the fix is really so simple, can't it be automated? -- Didi
----- Original Message ----- From: "Yedidyah Bar David" <didi@redhat.com> Sent: Thursday, September 11, 2014 9:12:32 AM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: devel@ovirt.org Sent: Thursday, September 11, 2014 4:04:23 PM Subject: [ovirt-devel] [ATTN] Changing messages with variable placeholders
all,
in general, changing non-English messages in the code is forbidden, as these are pulled automatically from the translation management system (Zanata).
HOWEVER: changing non-English messages in the code is *a must* in case not doing so will result in maven build failure.
this can happen when changing the quantity of variable placeholders in localized messages.
example:
let's say that I have an English message: "xxx {0} yyy {1}" and the parallel non-English messages are: "aaa {0} bbb {1}", "ccc ddd {0} {1}", "{1} eee fff {0}", etc.
If I am changing the English message to be: "xxx {0}" but leaving the parallel non-English messages as is: "aaa {0} bbb {1}", "ccc ddd {0} {1}", "eee {1} fff {0}", etc.
now the messages for the same key in different locales have different amounts of variable placeholders in them. this would result in a mvn build error.
** so whenever changing the quantity of variable placeholders in an English message, you must change the parallel non-English messages to match the new variable placeholders quantity. **
in the example above: the "{1}" placeholder (that was removed from the English message) should be removed from the non-English messages, so that the updated non-English messages would be: "aaa {0} bbb", "ccc ddd {0}", "eee fff {0}", etc.
you don't need to worry about the correctness of the non-English messages that you are changing; this will be taken care of in the translation cycle that will follow your patch. you just need to do the minimal changes necessary (remove placeholders / append placeholders) so that build errors will not occur.
NOTE: this can be very easily missed, as this type of build error will occur only when building the project with non-English locales (e.g. with the "BUILD_LOCALES=1" parameter within the "make" command in a devel env). So please - pay extra attention when making this kind of messages changes; if in doubt - build with "BUILD_LOCALES=1" and/or ask.
Let me know if you have any questions.
Many thanks in advance.
If the fix is really so simple, can't it be automated?
not sure exactly what you mean: automated how? once the developer changes an English message, when will the automatic change of the non-English messages occur? upon saving the English file? pre-compilation? and the developer still needs to be aware that non-English message files have been changes, so he won't forget to include them in the patch?... in any case: everyone are more than welcome to send patches for an automated solution, if there is any; until then - need to pay attention. thanks.
-- Didi
On 11/09/14 15:04, Einav Cohen wrote:
you don't need to worry about the correctness of the non-English messages that you are changing; this will be taken care of in the translation cycle that will follow your patch. you just need to do the minimal changes necessary (remove placeholders / append placeholders) so that build errors will not occur.
so before these changes get released in an official GA build there must be another translation cycle? as far as I understand this occured during composition of 3.5 and as far as I know there is no new translation cycle planned for 3.5? This would mean you would break translations in 3.5, wouldn't it? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
----- Original Message ----- From: "Sven Kieske" <s.kieske@mittwald.de> Sent: Thursday, September 11, 2014 11:08:35 AM
On 11/09/14 15:04, Einav Cohen wrote:
you don't need to worry about the correctness of the non-English messages that you are changing; this will be taken care of in the translation cycle that will follow your patch. you just need to do the minimal changes necessary (remove placeholders / append placeholders) so that build errors will not occur.
so before these changes get released in an official GA build there must be another translation cycle?
as far as I understand this occured during composition of 3.5 and as far as I know there is no new translation cycle planned for 3.5?
This would mean you would break translations in 3.5, wouldn't it?
the problem is more general then the specific issue I originally raised: once the last translation cycle has ended, yes - there are going to be inconsistencies between English strings and translated strings: every English text added to/edited in the code (it doesn't have to be a variable placeholder change, this is just one possibility) post the last translation cycle will get out-of-sync with its parallel non-English translation. the ovirt project translation involves orchestration of a large number of resources - tools, people, each of which in his own timezone, has its own limitations, schedule, etc. therefore it is pretty-much impossible to keep all translations constantly up-to-date, but we are doing the best that we possibly can. also need to keep in mind that towards the GA we are trying to do as little changes as we possibly can. Any translation update may result in breaking the GUI layout in some locales, etc. - and we want to avoid introducing instabilities to the project as much as possible at this stage. thanks.
-- Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
participants (3)
-
Einav Cohen -
Sven Kieske -
Yedidyah Bar David