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

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

We are agreeing on many points here. Let me expand on one idea that I think I'm not making clear. I am a native English speaker. As an English speaking software engineer, when I've created labels, messages, etc I usually think they are pretty good. However, I work at a big company, so we have people who are technical writers. They are experts in how these kinds of strings should be written for the highest quality professional English. Based on their feedback, it turns out I'm not quite as good at how English labels, messages, etc should be written for the highest quality professionalism. I understand the language, of course, but sometimes I'm influenced by my engineering background to take shortcuts or represent things the wrong way. It's rare for somebody to be both an expert software engineer and an expert English speaker. The kind of feedback you are asking for in your code review is going to require that sort of dual-expertise in order to accurately assess if your code solution will allow high quality, professional translations for all languages. Maybe OpenStack has attracted people with that sort of background, but if so we are really quite lucky. It's a difficult question for people so sort out. I still hold that we need to get rid of most of this concatination in order for Horizon to be most effectively translated. I understand that may result in more translatable strings, but I'm hopeful that will be outweighed by the fact the context and usage of those strings will be clear, and people without coding expertise will be able to easily understand and contribute to the translation of Horizon. My only word of caution is that I am only beginning to understand what removing concatination means for the Horizon/Dashboard code base. I think there is only a limited amount of code that actually does concatinations, but it's used to generate a great deal of the UI. I really should quit spending time on the mailing list, and start digging around in the code on this one! :-) Doug Fish From: Yves-Gwenaël Bourhis <yves-gwenael.bourhis@cloudwatt.com> To: openstack-i18n@lists.openstack.org, Date: 05/02/2014 04:57 AM Subject: Re: [Openstack-i18n] I18n meeting tomorrow Le 30/04/2014 18:47, Douglas Fish a écrit : translations? The problem is that they work now in French... and probably many more languages. But I'm no expert in other languages to certify they would work in "all" languages. Maybe some languages would require not using variables in the string and to have the full string. I really need other language speaking people to check this point while reviewing the patch. I only speak English and French (and my German notions do not meet all the requirements :-) ) to know that what is right in one of them can be wrong in one of the others, and finding what is "dynamically" right in these is already extremely difficult.

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.

This is why my current patch needs to be reviewed especially by people who speak different languages. I would need a German, Japanese, Chinese, Spanish, Russian, etc... native speaker to review this. The issue is that it's not trivial to have someone knowing translations and being able to read python code (or vice-versa) at the same time. This really is not an easy issue, the difficulty is not in terms of coding but of how to implement it to meet world-wide requirements. 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.

I totally agree :-) -- Yves-Gwenaël Bourhis _______________________________________________ Openstack-i18n mailing list Openstack-i18n@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n