Q: Context protocols

[mwpowellhtx]

According to this article, Context may be conveyed using a double-pipe ("||") delimited string prefixing the msgId. 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 the gettext 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 for NGettext assumptions, mind you. i.e.

pgettext ("Menu|", "File")
pgettext ("Menu|", "Printer")
pgettext ("Menu|File|", "Open")
pgettext ("Menu|File|", "New")
pgettext ("Menu|Printer|", "Select")
pgettext ("Menu|Printer|", "Open")
pgettext ("Menu|Printer|", "Connect")

Cheers, best. 🍻

[VitaliiTsilnyk]

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.

[mwpowellhtx]

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! 🍻