Coming from this discussion and from my experience with gettext
Is your feature request related to a problem? Please describe.
Some times a same message can be translated differently depending on context, so catalog should contains as many as entries as needed
Describe the solution you'd like
A way to handle hierarchical structure of message id or abstraction around context option / attribute
Describe alternatives you've considered
I tried id with prefixed message but it could lead to translation error.
Hey @JSteunou,
unfortunatelly, context isn't supported at the moment. @FredyC also come across msgctx while improving po file support, but we agreed we won't include it at the moment.
Possible workaround is either to use message ID context.id with default message or add context to default message ((context) message). In upcoming release, there's gonna be support for message descriptions, so you can communicate with translator what kind of message is it.
I believe we could support message context even without breaking the app completely. We could join message descriptor into single ID during compile if app uses context. For that we need to figure out how to transform IDs in production code, similar to #139.
I'll leave it open for now, but considering possible workarounds, it has a little priority. I'm open to suggestions!
In react-intl, I've used the description property for this purpose. It's not hierarchical, but it is pretty effective for communicating differences between otherwise identical phrases.
Would that be difficult to implement?
@alampros It should be difficult and I'm already planning to add support for description as part of #197.
It's an alternative solution, but for now it might be good enough.
The only problem with description approach is if you have for example an expression Order in two places and in each of them it means something different. It would still be as one message in a catalog and it cannot have a different meaning. A workaround is to use custom IDs which can add necessary context, but it's not that pretty.
Exactly, that's why consider it alternative solution.
For messages used as keys, we need to provide extra ID with context:
<Trans id="Top (Direction)" description="Top in context of direction">Top</Trans>
<Trans id="Top (Filter)" description="Filter in context of filter">Top</Trans>
For custom IDs it's actually not much a problem:
<Trans id="top.direction" description="Filter in context of direction">Filter</Trans>
<Trans id="top.filter" description="Filter in context of filter">Filter</Trans>
So, it's one extra attribute on Trans component vs supporting context directly. We might add a better solution when we add more features to compiling - for example, message descriptor { id: "Top", context: "Filter" } would me serialized to Filter|Top (while all other messages would be simply "|Message"). This would be just a compile step, so translator receives msgid and msgctx as expected. When we actually add #139, this wouldn't increase catalog size, because message IDs will be shortened anyway. But that's just an idea at the moment...
Support for message description released in v2.7.0.
Context isn't planned at the moment. We might get back to this in the future.
And how do you specify description with t macro? It's not really mentioned in docs, just as description prop on React component.
@FredyC Ops, I missed that. Here it is: https://lingui.js.org/ref/macro.html#description
Most helpful comment
Hey @JSteunou,
unfortunatelly, context isn't supported at the moment. @FredyC also come across msgctx while improving po file support, but we agreed we won't include it at the moment.
Possible workaround is either to use message ID
context.idwith default message or add context to default message ((context) message). In upcoming release, there's gonna be support for message descriptions, so you can communicate with translator what kind of message is it.I believe we could support message context even without breaking the app completely. We could join message descriptor into single ID during compile if app uses context. For that we need to figure out how to transform IDs in production code, similar to #139.
I'll leave it open for now, but considering possible workarounds, it has a little priority. I'm open to suggestions!