[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