-
Notifications
You must be signed in to change notification settings - Fork 156
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
Comment should make unique nugget #90
Comments
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. 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). 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 |
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 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. |
Actually it is supported by the app we're using (www.poeditor.com). I've created a sample po file:
|
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. |
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 Am I doing anything wrong? |
Hopefully that fixes it, please let me know. |
👍 |
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.
The text was updated successfully, but these errors were encountered: