Open mwpowellhtx opened 1 month ago
Not sure if I got your question, but CONTEXT_GLUE
has nothing to do with how you define your own contexts. You can use "Menu|Printer|" with no problem as a GetParticularString
method argument.
It also has nothing to do with .PO files either, as they have a separate directive msgctxt
for contexts.
The context glue just something to do with how the gettext utilities work internally with the contexts and how they load the compiled translation files (.MO files). It is specified in the GNU MO file specifications. But you, as an API consumer, should never worry about it. Any GNU/Gettext-compatible utility will compile a .MO file with the EOT character as a separator between the context and the message id. And NGettext will load those files regardless of what generated those files as long as it follows the standard.
Well, yes, exactly, we are compiling from PO to MO files. We deploy the MO files.
We integrate NGettext
to load the files.
But if I understand correctly, these two layers are, technically, separate and distinct, from a a separators integration perspective.
So in this context (pardon the verbiage confusion), we do not need to worry about it, we can use our own separators to define context
from msgId
? I gather, yes.
Cool! 🍻
According to this article, Context may be conveyed using a
double-pipe
("||"
) delimited string prefixing themsgId
. Although granted I think the phrase.com article may be concerning their gettext adoption, definitions, etc.I see in your source code, the specification of a
CONTEXT_GLUE
constant, something like an EOT character, which although I do not think there is anything in thegettext
protocols that says it has to be a pipe, or an EOT, or any other specific character, but EOT seems an odd choice.And in .PO - gettext files (Strings), referencing notes around
msgctxt context
and such.Anyway, how does that work interfacing with
ICatalog
? Can we train the catalog otherwise, how are we to define the.PO
given the NGettext opinions on the character, I gather there should be some configuration there?What's the guidance there, if you don't mind, please? Overall, i.e. Using contexts for solving ambiguities? And specifically re:
NGettext
.At least based on the GNU utilities, they've identified the pipe character (
'|'
), and may even specify paths as such. This is something I am deciding is a pretty good idea, personally. Excepting forNGettext
assumptions, mind you. i.e.Cheers, best. 🍻