Comment should make unique nugget
rickardliljeberg opened this issue · comments
If I put the following three in my view
[#[state]#]
[#[state///a condition (i.e. state of mind)]#]
[#[state///geographical state]#]
they will all come together with one translation for them all which is not correct. for instance translating to Swedish the two kinds of state are very different words.
There is a workaround currently that you can write
[#[state]#]
[#[state1///a condition]#]
[#[state2///geographical state]#]
that way they will get unique entries. however then it wont look very pretty if you miss a translation for them.
Hi Rickard, I think that would mean the comment would be included in the PO msgid somehow, otherwise you would have multiple messages with the same 'key'? Is that what you're saying?
Interesting to see you have standardized on [#[nugget]#] for your project. I was researching some AngularJS stuff recently and noticed that the Google guys had done something very similar there, but they only used double braces i.e. [[nugget]]. Their thinking on i18n of web apps was in tune with ours here, however.
Martin
I browsed the topic here on nugget delimiter problems and picked this one([#[ ]#]), which is a hassle to type on swedish keyboard so not optimal, but at least no matrix collisions.
Interesting to see that google is on the same track, i love this project now. very handy, takes minutes to throw in a new project.
On the topic.
I think if we have the comment as part of the nugget key we would avoid this problem and also comments are filtered out which means that even if we don't translate it we still only get "state" (without comment).
However of course we do not want the comment in the po-file-key for the translators.
So the postbuild parser would simply print the same key many times (i think that is allowed) but with different comments.
Then the parser would simply have to take comment into account so when finding a word it must not only look for key but also comment (if nugget contains comment).
Question is if that part would increase complexity and decrease performance.
so basically new key is key+comment
Thinking loud one could also have a different comment such as //! that means force separate entry where /// happily merges on to any existing entry. altho i think this part is unnecessary.
Yes, I think that will work from our end, but it is a big IF as to whether PO files are allowed duplicate msgids (with differing comments). That needs confirmation. It then may work with some PO editrs but not with others.
If not, your idea of a special comment that get's included in msgid but stripped during nugget substitution would work.
So for nugget [#[state//!geographic]#] we have msgid of state//!geographic which is translated by default to just state
According to this answer
http://stackoverflow.com/questions/5895205/multiple-msgid-for-an-msgstr-in-gettext
there is a msgctx that can be used to differentiade identical msgid with different translations.
and looking here: http://www.gnu.org/software/gettext/manual/html_node/PO-Files.html
it seems to confirm that you can basically put each message id within a context.
altho i suppose context was meant more as namespaces orginally, i see no problem in the spec to simply to put the comment in the context.
so then i suppose the question is, put all comments as a context and separate them, or introduce a new delimiter that creates comment and at the same time puts it in a context.
I think putting all comments in context would be the better as the other requires knowlledge about all the strings in the project which can be tricky.
It could also simply be a setting in web.config, put all items with comment in their own context.
Hmmm, interesting, msgctx could be the very thing. I guess it depends on how PO editors work with it.
I've just tried PoEdit and the current release doesn't support it although this may recently have been fixed in the tool's source code but yet to be released.
Have you tried your editor?
Hmm your are quite right, I also use poedit and it lacks support at the moment.
too bad, then i suppose the only current solution is something like this
[#[state%%%geographical]#]
but even that has it's major drawbacks, because even if we filter away %%%geographical in the parser we cannot filter it away from the po file. so then the key and thus what translators see will be state%%%georaphical.
something that would cause confusion for sure.
I suppose there is no way to avoid getting something in to the msgid unless the context one is supported.
Funny, this must be a common problem?
Have you found any solution to this problem?
Sadly not, the correct way to go is the msgctx.
however until poedit or another good translation app supports it, then it's not much point
Actually it is supported by the app we're using (www.poeditor.com).
I've created a sample po file:
#: D:\mvc\Website\Views\Test\Index.cshtml:6
msgctxt "zxc"
msgid "Testing Testing Testing"
msgstr ""
#: D:\mvc\Website\Views\Test\Index.cshtml:7
msgctxt "asd"
msgid "Testing Testing Testing"
msgstr ""
and the app picket it up:
Hmm when i tried it in POEdit then it failed completely
but if there are editors out there workign it would be pretty nice to implement.
could have it as a setting so people using poedit don't need to use it.
I've just pushed an implementation of this as requested.
See the Message Context Support section of the readme for instructions.
Essentially, it is now possible to route the ///comment value into a msgctxt field.
It seems to work although with limited testing.
One issue is that long comments are probably inappropriate for this. We could look for markup in the comment and truncate at that for the msgctxt. There again, if we do that we may as well extend the nugget syntax to include msgctxt.
Works great - thanks a lot!
I'm probably missing something, but I don't get the msgctxt in the .POT-file, only in the .PO-file.
I do have the i18n.MessageContextEnabledFromComment" value="true" in my appSettings
Am I doing anything wrong?
Hopefully that fixes it, please let me know.
👍