Message context for Yii::t()

[Deele]

I feel that Yii::t() lacks ability to provide context of textual value and when translations start to count in couple hundreds, it starts to be quite hard to understand what was meant with translation.

If we look at popular translation systems like "Crowdin" (example), they allow to provide message context to support translators.

Currently, only way to provide some helpful information using Yii::t() is to write something in "key" area, that in turn defies purpose of "source language", for example, if you write a message "Propose (button in issue tasklist table header)" until I change that translation to "Propose", that message still be visible.

I am guessing, that there is performance issue with long keys, and length limitations does not allow long context descriptions.

For backwards compatability, I would like to suggest 5th optional attribute to Yii::t($category, $message, $params = [], $language = null, $context = null) (but this is not very convenient) that would allow to provide some sort of context description.

Maybe, we could convert Yii::t() to allow passing in first attribute array of attributes, like Yii::t(['category' => 'message.category', 'message' => 'message text', 'params' => [], 'language' => null, 'context' => null]) or even allow shorthand for category and message with numeric keys Yii::t(['message.category', 'message text', 'params' => [], 'language' => null, 'context' => null]).

With \yii\i18n\DbMessageSource, they would be stored in separate table source_message__context, where we would store source message ID and context description with 255 characters long string.

With \yii\i18n\PhpMessageSource, they would be stored in separate file, right next to current message files, in {category}_context.php format, where we would have associative array with source message category as a key, and array with context descriptions, as a value.

I have no experience with \yii\i18n\GettextMessageSource, but I see in their documentation, that they already have an option to provide context descriptions. But I would like to see some suggestions for this solution.

This feature would allow to display all of those context description together with message in interface, to help translator to translate messages and understand context of it.

[samdark]

Getext context is what we know as a category, not an example of usage: https://www.gnu.org/software/gettext/manual/html_node/Contexts.html

[klimov-paul]

I am against such feature.
Placing some descriptive information around any call of Yii::t() sounds like overkill to me.

Besides how we can control same pair of 'category' and 'message' will have same 'context' at all its invocations? For example:

Yii::t('app', 'Some message', [], 'en', 'Some context');
// ...
Yii::t('app', 'Some message', [], 'en', 'Another context!!!');

Each translation message has unique key, which is a combination of category and message.
If you wish to add some description to them you can use this pair and your own custom wrapper.

[samdark]

Agree.

[Deele]

@klimov-paul I don't see arguments about such approach being overkill. I already explained how to control/store them. Each message can have multiple contexts as in your example. Nothing changes regarding identifiers.

[samdark]

@Deele

1. Not all formats we support allowing for such feature. GetText does not.
2. There's category to differentiate contexts.
3. You have to preview your translation somehow anyway. It's not possible to translate 100% perfectly w/o checking actual UI usage because of many factors: context which could not be effectively described in text, UI specifics etc.

[Renkas]

1. GetText supports comments: https://www.gnu.org/software/gettext/manual/html_node/PO-Files.html
2. it's not very descriptive. A freetext comment can be usefull sometimes.
3. Of course - but translators don't have that possibility usually (at the time of translation).

[samdark]

OK. If comments are supported in GetText we may introduce it.

[samdark]

Still, I don't think these descriptions are good to be placed right in the code.

[klimov-paul]

I don't see arguments about such approach being overkill.

For me internal program code should not contain such information since it does not influence the program logic. You propose to make source code, which will be executed on each(!) program run much heaiver to support translation functionality, which is performed relatively rare.

Yii::t() function serves the functioality purpose, while yii message command is a service. I do not like the idea to mix up functionality with the service.

Each message can have multiple contexts as in your example

And how it should look like in the end? How it should be stored? What it should mean for the interpreter who will work with translations?

One more thing. What you are planning to do in case your interface for the translations management should also provide i18n feature? This will mean that your 'context' should be translated as well. Otherwise it make not much sense then a plain message ID.

[klimov-paul]

GetText supports comments:

GetText instroduce sperated file per each language. So you mean 'context' may vary per each language in your case?
As far I can see 'context' is something universal through all language translations. Saving context inside GetText will just cause a lot of data duplication.

[Renkas]

Don't confuse comments with context/category.

[SilverFire]

With \yii\i18n\PhpMessageSource, they would be stored in separate file, right next to current message files, in {category}_context.php format, where we would have associative array with source message category as a key, and array with context descriptions, as a value.

I read this and can't find points why the aforementioned is worth than creating a separate dictionary for a specific context. I see the following cons:

• New entity
• More code to support
• More complexity to Yii::t API (passing 4-th argument after two optional)
• More complexity to messages resolving
• Need to re-write yii message, as @klimov-paul said in his last message

Therefore I'm standing against this feature request.