Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I18n strings should (optionally) contain a context #6662

Closed
danxuliu opened this issue Sep 27, 2017 · 2 comments
Closed

I18n strings should (optionally) contain a context #6662

danxuliu opened this issue Sep 27, 2017 · 2 comments

Comments

@danxuliu
Copy link
Member

danxuliu commented Sep 27, 2017

Currently it is not possible to provide a context for translators to easily know the context in which a string appears to decide the most appropriate translation. Moreover, English words like Favorite can either be a noun or a verb, but when translated to other languages a different string could be needed for each case, so a single translation for that string would not be enough. Due to this, it should be possible to optionally provide a context for internationalized strings.

The approach used by GNU gettext is simply to provide an extra parameter to the gettext call with the context; to keep the current API a possibility could be to extend the current app parameter to include the app name and, optionally, the context (for example, t('core Noun, type of file', 'Favorite') and t('core Verb, add to favorites', 'Favorite') instead of just t('core', 'Favorite')).

When translated, the string would become "Favorite": {"Noun, type of file": "First translation", "Verb, add to favorite": "Second translation"} instead of "Favorite": "Translation". The translation function would check if the context contains just the application name or some extended information, and in that case it would try to match the extended information with a key in the array of contextualized translations of the internationalized string; otherwise it would just assume that the internationalized string is associated with a single localized string and return that one.

I know nothing about Transifex, so I do not know if contexts are supported there, although I would be really surprised if they were not (personally I think that we should be using a Free Software translation tool like Pootle or something like that but that is a different matter :-P (calm down, sheathe your weapons, it was just an innocent comment, I know that changing the platform could be bad for translators... and that the admins are busy enough already ;-) )).

@danxuliu
Copy link
Member Author

I was wrong; currently it is possible to provide a context for translators to easily know the context in which a string appears to decide the most appropriate translation (just add a comment before the string beginning with TRANSLATORS).

However, if I am not mistaken, the second part of the opening paragraph is still valid. That is, although the translators can know the context and provide the appropriate translation for English words like Favorite that can either be a noun or a verb the context is external to the function that performs the translation at runtime; that function only gets Favorite (and in some cases the application name) as a parameter, and thus it can not replace the English word with the appropriate translation if there is more than one.

Anyway, this problem should be avoidable in most cases by taking some care with the English wording.

@danxuliu danxuliu added the low label Oct 24, 2017
@MorrisJobke
Copy link
Member

Anyway, this problem should be avoidable in most cases by taking some care with the English wording.

Yes. Most often it's not a problem because it is the very same word with two translations that is used, but to give better context for translators. The "Favorite" thing could happen and we avoided it, but it seems that this is more a corner case and we can think about it once it is really a problem.

I would close it. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants