"Improving the translation Process" DevCon UnConference topic

[Corné Aussems, modifié il y a 10 années.]

Hi all,

Because of the conversations lately;
Email warning
Disambiguation
Automatic translated keys

I'll type here some discussion and outcomes of the DevCon Unconference topic i initiate and for which i asked Julio Camarero as the Liferay representative;

Adding page context keys
We discussed how translators independently from the Liferay developers could translate specific uses of ambiguous keys.
Like the already working solution of disambiguation the idea was posed to add
a page or portlet context. For example if a key with title[users-admin/users/details_user_name] was present in the specific Language.properties this would only be used in this
/portlet/users_admin/user/details_user_name.jspf context.
Currently this would be hard to implement because the code responsible for replacing this has no sense of context. Even so it is (yet) impossible to add a key to a translation (see below)

Pootle Improvements and or replacing this
Emerging from an earlier post. Features as notification, history, communication, etc that would aid us in the translation process were discussed.
Julio explained the hardship that was endured getting Pootle working. A lot of fixes had been made since.
Most features are available in the a new stable release 2.5 of Pootle and Liferay would look into the possibility of upgrading Pootle or using better alternative solutions like Transfix.

Adding Translation improvements to GA2+ releases
Currently changes are pushed into the master/trunk, and are/were not integrated into the next GA of the previous (major) release.
We could have send a pull request. Last GA3 was still a miss and we hope in future releases this would be an automated process.

Scheduling translations
A wish was expressed to get a more timely notification of translation needing to be ready.
We somewhat concluded that any Béta release should set us off already. This years B1 was released on 2013-08-05 and RC1 a (theoretical) GA was released on 2013-09-21 leaving us 1,5 month to get it done.
For GA2 & GA3 there has been no notification which could be useful too.

Git Push translations
We can git push translation improvements to our languages. New keys can not be added to your translations but need to go into the default english before they get propagated to the other languages.

The night was long after the UnConference so if i forgot something please add your perspective to this thread.

Corné

[Daniel Sanz, modifié il y a 10 années.]

Hi Corne,

there's a lot of good stuff there. Thanks for sharing. Let me provide some thougths on those topics.

Corné Aussems:

Adding page context keys
We discussed how translators independently from the Liferay developers could translate specific uses of ambiguous keys.
Like the already working solution of disambiguation the idea was posed to add
a page or portlet context. For example if a key with title[users-admin/users/details_user_name] was present in the specific Language.properties this would only be used in this
/portlet/users_admin/user/details_user_name.jspf context.
Currently this would be hard to implement because the code responsible for replacing this has no sense of context. Even so it is (yet) impossible to add a key to a translation (see below)

So far, we are approaching this on a case-by-case basis. When such a disambiguation need is detected, the process is;
1. appropriate changes are pushed to the source code
2. New, context-dependent key(s) are declared in template file (Language.properties), keeping the original ('contextless') key
3. Pootle gets updated to make those new keys available for translation to all languages

In my view, assuming that every single key has as many contexts as the places where it's used is not very practical as it would create a combinatorial explosion in the number of keys. The notion of context for a key is language-dependent, so an over-usage of contexts would generally lead to a big bunch of keys which don't require specific translations for many languages. This is not bad per-se, but translators would have to face a Pootle interface full of slightly different keys and they'd had to check if, for their language, that key variation has to be translated or not. Otherwise, how would translators provide a value for a key in an specific context? For Pootle, all of those keys are just unrelated.

Moreover, this would have a clear impact in 2 cases:

• Refactorings & backports: when jsps get reorganized as a result of a refactoring, context names will change, which would force translators to review the meaning of those changes. In addition, key backporting to old versions (see below) would be almost impossible due to context would likely not match.
• Extensions: when extending Liferay, how will plugins reuse translations if keys are only valid for a given context. In addition, developers should be aware that rewriting a JSP may have side effects as some languages might assume a specific translation valid only in the original JSP.

As I see it, we should set up a quick dissambiguation process so that any translator can report it in an LPS and, as a result, in a few days, the problem gets fixed in the product.

Corné Aussems:

Pootle Improvements and or replacing this
Emerging from an earlier post. Features as notification, history, communication, etc that would aid us in the translation process were discussed.
Julio explained the hardship that was endured getting Pootle working. A lot of fixes had been made since.
Most features are available in the a new stable release 2.5 of Pootle and Liferay would look into the possibility of upgrading Pootle or using better alternative solutions like Transfix.

I have started to prepare an env with the latest pootle version. Fortunately, there seems that different django versions can co-exist in a same installation so I expect to have a working server soon. What I still don't know is how such an upgrade will affect the current sync process, which, as I' ve said in other threads, has several components which are pootle version-dependent.

Corné Aussems:

Adding Translation improvements to GA2+ releases
Currently changes are pushed into the master/trunk, and are/were not integrated into the next GA of the previous (major) release.
We could have send a pull request. Last GA3 was still a miss and we hope in future releases this would be an automated process.

The scripts we use for master <--> pootle sync include a backporter functionality which takes 2 branches and copies translations from a branch to another (supposedly older). We use that backporter to create language patches for previous Liferay EE versions as we have official support for some languages.

There are different cases when backporting a key. The backporter takes into account all of them and backports what can be directly copied to the destination branch. A few cases are sent to a review file as direct backport is not possible (for instance, if the English value of that key changes amongst versions). The interested can check the sources for details.

We can consider the possibility of applying the backporter to different major CE maintenance branches. I'll take note of this and talk to other participants in the process to know their view.

Corné Aussems:

Git Push translations
We can git push translation improvements to our languages. New keys can not be added to your translations but need to go into the default english before they get propagated to the other languages.

If I understood, you suggest the possibility of having a different set of keys (not translations, but keys) for specific languages, regardless of the contents of Language.properties file (which contains the english translation). Is that right?

This is not supported now, and I don't think it will be in a near future. Both pootle and our build-lang ant task (implemented in LangBuilder.java) force you to have the same set of keys for all languages, being that set defined in the language template (Language.properties file). That's the reason why any new key has to be defined first in Language.properties.

Maybe this schema does not fit well in case we'd have all that myriad of per-language-context-dependent keys. I believe that, if we switch to that schema, Language.properties would contain just the context-less key and any english, context-dependent value as well. However, it seems to me that this would have a big impact in the product, in the translation tool, which would have to embody this notion of context (Pootle seems not to do it, will check latest version) and in the sync code which allows to update pootle from liferay and the other way around.

Thoughts?

Thanks again!