[Openstack-i18n] [horizon] contextual-markers for better translations
Yves-Gwenaël Bourhis
yves-gwenael.bourhis at cloudwatt.com
Thu Apr 24 15:29:55 UTC 2014
Le 24/04/2014 16:32, François Bureau a écrit :
> Hello all,
>
> Today, we have talked with Yves-Gwenaël about this e-mail. He didn’t' received any answers and I think we need to discuss about it.
>
> I would like to know one thing, if we change a marker for a string are we going to lose the related current translation ?
Well, with command line po generation tools indeed you lose them.
> For example :
>
> currently I have somewhere month = gettext("May")
> So in transifex I have a string May I have translated in "Mai" (in French)
>
> If tomorrow you change into the code month = pgettext("month name", "May")
>
> Do we lost the translation already done in Transifex ? Or is it just going to add the context in the string already translated ?
Since I don't know how Transifex handles the po and mo files generation,
I prefer being pessimistic by saying: "I'm afraid you'd loose the
translation"...
> If we lost the translation already, for me adding the context into already translated string is a bad idea. We are going to lose too much work.
>
> And in this case the context markup has to be used only for new strings. I prefer to keep the legacy for old strings.
We can indeed add code reviewing rules where when each new string which
is less that 4 or 5 words (a brain storming between developers and
translators is required to decide how long/short a string has to be to
implement this rule) would require a context. And when a string requires
to be changed after code modifications, there also we would add a
context, so this would implement contextual-markers smoothly for
translators by not braking the existing translations unless they need to
be changed (because the original version/language changes).
> Thanks a lot for your answers :)
>
> Best regards,
--
Yves-Gwenaël Bourhis
More information about the Openstack-i18n
mailing list