3:04 p.m.
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
3:12 p.m.
----- Original Message -----
From: "Einav Cohen" <ecohen(a)redhat.com>
To: devel(a)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
3:31 p.m.
----- Original Message -----
From: "Yedidyah Bar David" <didi(a)redhat.com>
Sent: Thursday, September 11, 2014 9:12:32 AM
----- Original Message -----
> From: "Einav Cohen" <ecohen(a)redhat.com>
> To: devel(a)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
5:08 p.m.
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
8:24 p.m.
New subject: [ATTN] Changing messages with variable placeholders
----- Original Message -----
From: "Sven Kieske" <s.kieske(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
3536
days inactive
3536
days old
4 comments
3 participants
participants (3)
-
Einav Cohen -
Sven Kieske -
Yedidyah Bar David