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@cloudwatt.com> To: openstack-i18n@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
-- Yves-Gwenaël Bourhis _______________________________________________ Openstack-i18n mailing list Openstack-i18n@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n