-
Notifications
You must be signed in to change notification settings - Fork 84
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
Missing support for translation context #114
Comments
@dannote We have by design decided to not include contexts because, even in the original implementation, they are simply shortcut macros that can be implemented by the developer. Also, if you want to split different translations, domains may be better used to solve such problems. |
@josevalim AFAIK domains were designed to split translation files into modules and contexts were designed to store different translations for same phrases even within the same domain. For example, in a Phoenix application there are at least two separate domains - one for Ecto messages and one for UI. Imagine that we need two different translations for different models (that often happens for Russian). Should we then place each model into it's own domain? |
@dannote yes, I would use two different domains in this case. From what I understand about contexts, they are used to solve ambiguity arising from linguistic situations. For example, you can use "file" as a verb and as a noun in english, although that wouldn't work in other languages. It is a linguistic context rather than the application domain one. It could also be used when gender, adverbs and adjectives are involved. There is not a lot of information about gettext though, so I am not 100% sure. |
The idea is that you can have domains like |
I suppose that this feature won't bloat the library much. I can prepare PR for those four functions. Anyway, it would be nice to provide instructions for other developers who might require contexts. @spec pgettext(module, binary, binary, bindings) :: binary
def pgettext(backend, context, msgid, bindings \\ %{}) do
dgettext(backend, "default", "#{context}\u0004#{msgid}", bindings)
end |
The function you proposed requires people to write translations in PO files like that: msgid "my_contextUNICODESTUFFmsgid" which would not be optimal I think. What would then be the difference with doing |
I think it is best to document for now this is possible instead of On Wednesday, August 17, 2016, Andrea Leopardi notifications@github.com
José Valimwww.plataformatec.com.br |
@whatyouhide Sorry, that was a wrong suggestion. I thought that |
@dannote exactly, and that should be handled everywhere in Gettext. It would not be a small change, that's why me and José are trying to not do it until absolutely necessary (read: requested by several users). As someone once said, in open source, saying no is temporary, but saying yes is forever :) So let's wait to see if someone else is interested and maybe in the meantime you can try out the "rustic" strategy with simulating context similarly to how I showed in the example. And the docs, I'm gonna take care of those :) |
I just pushed 5e65d66 to master, which talks about "contexts" in the documentation for (PS: closing this issue for now, if you wander here because you want contexts in Gettext feel free to comment down here to keep the discussion going 😃) |
@josevalim , @whatyouhide I've never used the
|
Hey @stephenmoloney, thanks for pitching in (and for the kind words!). As of now, if you write # This is a pot file and this is a comment.
msgid "foo"
msgstr "" and run # This is a pot file and this is a comment
msgid "foo"
msgstr "" so this should already work? The alternative would be something like #83, where we attach comments from the developer to the translator, in the source code, alongside a translation. |
@whatyouhide Thanks for the reply, Sorry, yes, the comments work. The only thing I did notice and can reproduce is that if I change a comment, the new updated comment doesn't get merged back in. In
changed to
doesn't seem to update in the |
@stephenmoloney can you open an issue for that? I'll look into it. :) |
I' like to second @dannote's request to support disambiguating contexts, as explained here. It's true that anything you can do with contexts you can also do using domains, by creating domains with names like "navbar.archive", "body_text.archive" or something like that, as @josevalim suggested. The problem with this is that it creates multiple files per module, and restricts the context to the strings you'de choose for filenames. It doesn't allow you to write a freeform sentence like "Here 'S' is an abbreviation of Scope" (unless you want to deal with space in your filenames), as in the link above, or "Choose a sentence that contains all characters from the script used by your language" (also in the link above). Personally, I don't actually need the full power of contexts, and I can get by just fine with domains. My motivation for wanting domains is to avoid the clutter of several domain files. |
I would like to resurface this - the lack of this feature recently effed us with an internal project at the company I currently work for. We assumed that this is a full port of the original gettext, and were surprised to say the least. |
Given the requests, we will gladly accept a PR that implements this. Thanks! |
This would definitely help us as well. Due to external dependencies we can not use more than one file per language, but ensuring we can specify context for the translators we have to deal with using the standard solution provided by gettext sounds like the way to go. Do you have any guesstimate about the complexity of adding this? |
@Wijnand we already parse the |
Ok, thank you. I will take a quick look to see if I can do it. |
@Wijnand I don't think it would be the same as |
Closed by #228. |
The original gettext library has
pgettext
,npgettext
,dpgettext
anddpngettext
macros to provide different translations of the same phrases in different context. Those are very useful in case of there are short strings and their implementation is simple.The text was updated successfully, but these errors were encountered: