Message context for Yii::t() #5
Comments
|
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 |
|
I am against such feature. 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. |
|
Agree. |
|
@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. |
|
|
|
OK. If comments are supported in GetText we may introduce it. |
|
Still, I don't think these descriptions are good to be placed right in the code. |
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.
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. |
GetText instroduce sperated file per each language. So you mean 'context' may vary per each language in your case? |
|
Don't confuse comments with context/category. |
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:
Therefore I'm standing against this feature request. |
|
xgettext utility works like so:
I see the problem having comment in a method call. Couldn't the message parser support some kind of comments markup? /// Some hint for translators here
echo Yii::t('app', 'Awesome string');And for inline usage maybe the parser could be smart enough to recognise comment that is inserted immediately after method call? echo '<b>' . Yii::t('app', 'Awesome string')/* Some hint for translators here */ . '</b>';Of course the parser should then be able to work when there are two method calls and hints on same line (example for test case ;) ): echo '<b>' . Yii::t('app', 'Awesome string')/* Some hint for translators here */ . '</b> - <b>' . Yii::t('app', 'Another awesome string')/* Hint for the other string */ . '</b>'; |
|
@SilverFire so you dislike the idea because it means someone needs to re-write Anyway I don't really like the opening and closing of this thread in a short amount of time without waiting for answers to open questions. And down voting from Yii core developer without giving a reason after all the issues have been addressed is a very odd move. |
I was disturbed while writing a comment. Then found, that I've confused translators comments and context. 😒 @Renkas sorry |
We have provided all necessary explanations. We consider this feature is not worth the overcomlication of the code (both yii2 core internal and possible actual project one). We can not accept such changes into the main codebase in near future. However, you can implement this feature as a separated extension outside the |
|
@klimov-paul I don't think you read the last posts here ... There's exactly 0 changes to Yii core code. Only thing that needs changing is message extraction and some documentation |
|
So you consider |
|
I haven't said that. If it would not be a part of Yii then there would be no point for this thread would it? But it's not part of core code as you said - core code would run perfectly fine without it. It's an utility - and quite useful one (at least for me). Support for message hints (should be the proper name for this feature I think?) is currently missing from it. And I don't really see why it could not be a part of the default functionality. Right now it seems you just try to defend the decision on why the issue is closed and are not even thinking about the new proposal. That's not a very productive way of improving anything (which is what software development is all about I think?). Anyway I'm not going to debate you on this anymore. If Yii team has made up it's mind then so be it. If I really need it I'll implement it myself - just seems like a thing that would probably be useful for lot's of developers. |
|
@Renkas Can't you use actual message as descriptive context? What I mean is, set 'Welcome {user} # some context' => "Welcome {user}"` |
|
Of course this is a possible hack and as far as I have seen from forum threads etc some people use it. But it's still kind of a hack. My projects are all using proper base language as strings as I'm not a fan of this dummy language solution. But that's just my preference ... |
|
I'd like to discuss it a bit more after some thinking. Adding more functionality to message parser isn't a big problem. The problem is not to complicate default usage which doesn't have this context. Using comments for the purpose looks a bit like hacking to me and, as @klimov-paul said, it adds load to APC/OpCache requiring more memory to store these. @Deele, @Renkas do you want these comments to appear strictly in the code or you just want them to be there to be filled later? |
|
Me personally would like the possibility to write some hints/explanations to the translators when needed. In my use case I use parser to generate gettext files that are then synced to external translation service and then synced back to my application (overwriting the parsed .po files). So what I want is a mechanism for the message parser to get these message hints from my application source code and save it to the generated .po file - which will be synced to the external service and the hints will be available there for translators.
Of course there are other message sources to think about. In PHP message source I think they could be used as PHP comments as well? And in DB message source maybe add a extra column? |
|
The message and category are key fields with limited length and other limitations. I don't want to disturb this behavior, that is why putting more information in category or the message does not really work. I want separate field, that is not keyed and indexed and could be provided within code. I agree to @klimov-paul that there is a problem of overhead because of descriptions that are parsed in every code execution. That could be handled with use of comments as @Renkas proposed, but that could become ugly for multiple inline If it is not possible to provide context description within code itself, then this feature should be handled separately altogether without changes to Another idea is to gather and make available other kind of message context information - where exactly in code that specific |
|
I'm against expanding method signature but comments approach looks at least acceptable:
Sounds like a plan to me. |
|
Here is an idea how to solve the problem of passing a hint for translator on how to translate the message. Yii::t('app', 'Some message text'); // message without hint
Yii::t('app', '[[When translating this message take into account the following ...]]Another message text'); // message with hintIn the example above the Yii2 engine code impact:
Anyone sees any drawbacks in this approach other than (slight?) performance impact? |
|
You're mixing message itself with a hint in a single string. Usually that's not a good thing to do and in this case, while better than previous options, it isn't as well... |
|
@lynicidn The context is required because you can have message that is related to the same page, form or block, but still, it requires a bit explanation so that translator can understand better the gist of it. For example, when message string contains variables and translator needs to know what sort of thing is meant to go there. @PowerGamer1 Message string is used as a key to identify message, making it longer just gives bigger overhead for translation lookup procedure. @samdark To wrap it up from my point of view, this is what script procedure should look like in order of precedence (correct me if I'm wrong): 1. Multi-line comment right after
|
|
How about nested |
|
How or why would you nest |
|
See #8286 |
|
Well message parser handles it - couldn't it handle comments as well? But in a bigger picture I think it's kind of a edge case that is very easy to write in some other way if you need to add context hints. |
|
This long example is a great way of showing how overcomplicated comment hints can become. I would drop this idea in favour of category context mentioned earlier. Or we could always extend signature a bit so category can be optional array with first element being category name itself and second one being a context hint - this way is much easier to track. |
|
I would drop multi-line comment support and everything would be much easier. There's no need to go the route to support every possible comment markup and position. It would be nice but it's not necessary. These hint's are optional and good practice would be to use them only where needed. |
|
@samdark I disagree for nested calls. @bizley No, I do not agree that categories are enough for that. They are just like folders and give simple hierarchy while not exactly explaining what variables do or how this text is used. I think for starters, the 1. Multi-line comment right after |
|
@Deele nested calls are reality. They're used often: echo Yii::t('app', 'here is {something}', [
'something' => Yii::t('app', 'another string'),
]); |
|
@samdark Oh, sorry, I imagined another thing with "nested calls" - yeah, nested calls are reality and used. But the most important thing here is that they do not help to explain, to give hints about context, they just make work of translators even worse - any kind of chopping up messages and creating more of them, or increasing number of variables in messages increase work. |
|
@Deele What about array parameter for category? |
|
@bizley What exactly did you mean by "array parameter", show us example. The only alternative to comments I see - fifth argument for the Yii::t() function, that will require providing optional third and fourth argument. The problem is that translator never sees the code where that specific |
|
@Deele like I said in my comment. Something like: |
|
@bizley We should avoid changing syntax of existing |
|
I think we have listed here all the caveats. Let's wait now for implementation proposal. |
|
Hi, I drafted implementation of this feature in Yii2 yiisoft/yii2#17137 . Afterwards, I'll port it also to Yii3, but right know I need to use id in Yii2 framework. Thx. |
|
@FilipBenco than you! Unfortunately, 2.0 doesn't accept enhancements since last year with little exceptions. |
|
That's a pity. @samdark and if I port this feature also to Yii3? I really would like to have this feature and to be integrated directly into Yii2. This way both version will have this. |
|
Hi @FilipBenco, Although we understand your pain here, Yii 2 is officially in feature-freeze mode and we cannot bend that rule now, or else we'll open the door for more requests like that. You can probably make a separate package for yii2 and share it with other developers. I'll adopt it in my Yii2 projects where I have faced this context problem. I'm also really interested in seeing this land in Yii 3, don't hesitate to ping me on slack if you need help porting it. |
|
In order to add this feature later we need to ensure that extra context could be passed to the message of interface MessageWriterInterface
{
public function write(string $category, string $locale, array $messages): void;
}That won't affect the interface itself but will affect format of 'key' => ['translation' => 'string', ...] |
|
Interface part in this package and PHP / DB writers are done. |
|
The rest should be implemented in the message parsing tool. |
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, likeYii::t(['category' => 'message.category', 'message' => 'message text', 'params' => [], 'language' => null, 'context' => null])or even allow shorthand forcategoryandmessagewith numeric keysYii::t(['message.category', 'message text', 'params' => [], 'language' => null, 'context' => null]).With
\yii\i18n\DbMessageSource, they would be stored in separate tablesource_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.phpformat, 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.
The text was updated successfully, but these errors were encountered: