Open Stack

I was just discussing a similar issue in IRC #openstack-translation

It's my impression that the fixes you've proposed are patches that
gradually improve the translatability of Horizon, but don't address the key
issue:  the concatenation that is used to reduce the number of messages
results in complex and ultimately inaccurate translations.  Maybe I've
misunderstood the fixes?  Can they result in broadly accurate translations?

Getting translation right is important.  Having translations that are
maintainable and accurate are necessary for Horizon to reach maturity.  If
the solution you've proposed is "right", then that's great.  But if it
isn't right, I'd rather see us invest in refactor/retranslation now, in
Juno, rather than later.  The longer we wait to make this right the bigger
Horizon's code and translations are going to be and the harder they are
going to be to fix.

Doug Fish




From:	Yves-Gwenaël Bourhis <yves-gwenael.bourhis at cloudwatt.com>
To:	openstack-i18n at lists.openstack.org,
Date:	04/30/2014 11:10 AM
Subject:	Re: [Openstack-i18n] I18n meeting tomorrow



Le 30/04/2014 11:01, Ying Chun Guo a écrit :
> Hello, all
>
> At the meeting at the beginning of April, we decided to move the
> Europe/India friendly meeting time 1 hour later.
> So let's meet on at UTC 0800 tomorrow in the channel
"#openstack-meeting".

Hi all,

I totally forgot that tomorrow is a bank holiday in France...
I'll do my best to be there, but can't promise at 100% that my kids and
my wife will let me have the time to be present :-)
So I'll expose my concern here as a starting point.

> We could discuss following items:
> * Including the final : with strings
> (
http://lists.openstack.org/pipermail/openstack-i18n/2014-April/000573.html)
>
> * contextual-markers for better translations
> (
http://lists.openstack.org/pipermail/openstack-i18n/2014-April/000528.html)

Some details will be "technical" for translators so I hope I won't lose
them before the end of this mail :-) but I need to expose some technical
details to coders too, because it's how us coders do our job that we
make translations easy or impossible...

The issue is that the magic performed by the
"BatchActions._get_action_name" method in the code works really like
magic in "English", but is stuck to "English" and will never work
properly "as is" for internationalization...
Indeed, e.g. in French but also many other languages you need (depending
on the context and the action) an action_present_singular,
action_present_plural action_past_singular, action_past_plural (in
English only action_present and action_past) because the verb needs to
be conjugated depending on the number of concerned subject(s).

IMHO it would be much simpler if "action_present" and "action_past"
where removed and "_get_action_name" was replaced by a method receiving
the number of items as parameter and returning an
npgettext_lazy(context, singular, plural, number).
I think it's the best for "all" languages, otherwise we'll need a hack
per language like:
https://review.openstack.org/57701
https://review.openstack.org/91338 (core devs: please do not validate
this patch yet :-) )

The first problem about replacing the "_get_action_name" method and the
existing class properties is that it implies tons of refactoring...
The second problem is that it would totally destroy all the existing
translations... So I did not go that way...
The small patch I pushed here: https://review.openstack.org/91338
exposes the issue of the current method.
This patch keeps the existing and only requires "re-translating" the 2
actions I modified, and allows "progressive changes" to be done.
I don't know if this patch is adapted to all languages, so I need people
speaking different languages to comment on the patch to know if it
allows translating to their language.
What I want to avoid is needing multiple patches per languages. I would
like to to handle all languages gracefully.

What I would suggest is that I still modify
https://review.openstack.org/91338 in order to keep the old behavior,
and to add another method/way of translating, by running
"_get_action_name" only on existing implementations, and a new method
instead if the new method is defined on the sub_class.

So, I think that to avoid losing the work our translators already did,
we need to implement contextual markers "smoothly" and not all in one
go. This means we might need new code reviewing rules where reviewers
would not accept a patch if a new translatable string does not have
contextual markers, and that if a change is done to a translatable
string, since it would have to be re-translated contextual markers
should be added.
However long strings usually hold the context by themselves, so
contextual markers are required for short strings only and this is where
code reviewers will have to be able to detect if a string needs these
markers.
With these coding/reviewing rules we would introduce the contextual
markers progressively and not loose the work the translators already did
in just one shot.

However, these rules would have to be documented here:
http://docs.openstack.org/developer/horizon/
So that contributers know what is "legacy" to avoid braking the huge
amount of existing translations, and that they should use the new way of
performing.
This way, we would progressively remove all legacy code/translations to
finally have strings which make translations easy.

Our translators have already had some hard time for current translations
so we would not brake their work if we do this progressively by keeping
the legacy code/strings, however, when a change is required, the
contextual markers on new or modified short strings imposed by
coding/reviewing rules would allow them to make new translations and
changes with more ease than before.

Let me know if anything was unclear, and I hope I haven't lost anyone in
this loooooong mail :-)

> * I18n related sessions in design summit
> * Open discussions
>
> See you there.
>
> Best regards
> Ying Chun Guo (Daisy)
>
>
> _______________________________________________
> Openstack-i18n mailing list
> Openstack-i18n at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
>

--
Yves-Gwenaël Bourhis

_______________________________________________
Openstack-i18n mailing list
Openstack-i18n at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n