@garikkh is attempting to deploy a commit to the Crowdin Team on Vercel.

A member of the Team first needs to authorize it.

Codecov Report

❌ Patch coverage is 90.00000% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 76.70%. Comparing base (6bb8983) to head (7439a28).
⚠️ Report is 241 commits behind head on main.

@@            Coverage Diff             @@
##             main    #2347      +/-   ##
==========================================
- Coverage   77.05%   76.70%   -0.35%     
==========================================
  Files          84      100      +16     
  Lines        2157     2739     +582     
  Branches      555      713     +158     
==========================================
+ Hits         1662     2101     +439     
- Misses        382      509     +127     
- Partials      113      129      +16     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Ah, didn't work properly, need to continue working on it

I think implementation is suboptimal, instead of introducing another type of comment, simply print the same comments many times

#. js-lingui:icu=%7BanotherCount%2C+plural%2C+one+%7Bone+book%7D+other+%7Bmany+books%7D%7D&pluralize_on=anotherCount
#. js-lingui:icu=%7Bcount%2C+plural%2C+one+%7Bone+book%7D+other+%7Bmany+books%7D%7D&pluralize_on=count
#: src/App.tsx:61
msgid "one book"
msgid_plural "many books"
msgstr[0] "one book"
msgstr[1] "many books"

When deserializing just take to consideration that there could be multiple comments, flat map 1 message + 1 comment and use existing methods to process that.

I considered that approach, but it seemed messier to me when you have many duplicates. In our codebase, we've only been using lingui a few months, but already have cases with ~7 duplicates. So now you'd have a PO entry with 7 ICU comments instead of 1 really long comment.

instead of introducing another type of comment

Also wanted to note, this isn't introducing another comment - it's just using the icu comment. the ICU comment is a URLSearchParams, so all I did is add another key here.

  const contextComment = item.extractedComments
    .find((comment) => comment.startsWith(ctxPrefix))
    ?.substring(ctxPrefix.length)
  const ctx = new URLSearchParams(contextComment)

This solution is a little more complex, but IMO is more elegant/consistent

bump @timofei-iatsenko

@garikkh i pushed a commit to your branch with a refactoring and some changes:

• instead of extra other_pluralize_vars param it uses existing pluralize_on just listing all variables in it.
• it doesn't use a first UCI message in a merged message, instead it replaces original value to some dummy var placeholder. There is no sense semntically to use a first occurance, it's confusing, so instead it make it generic.
• i refactored code, removed duplication, added a typesafety for ctx object.
• one extra change - i made an context comment more readable like so: js-lingui:icu={var, plural, one {one book} other {many books}}&pluralize_on=count,anotherCount,thirdCount,manyCount,superLongVariableNameIsOkayCount

I will update PR description and docs, so it could be used as release notes.

Some TMS might not allow duplicate msgid, even with different comments, and should use mergePlurals option to merge these entries into a single PO entry during extraction.

From how I understand PO spec, the msgid should be uniq, so i'm not sure there are TMSes which would process duplicated msgid without errors. So i believe this mergePlurals should be enabled by default because disabling it leads to broken/invalid po file.

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Updated (UTC)
js-lingui	Ready	Preview	Dec 10, 2025 3:40pm

Thank you for the changes + merge!

Unfortunately the last change you mentioned breaks our TMS again

Same issue as in #2004 - if a comment gets too long, our TMS breaks it up into multiple lines, and multiple lines don't get parsed correctly in lingui

With this change, we have an entry:

#. jsi18nicu={hours, plural, one {{hours} hr} other {{hours} hrs}}&pluralize_on=hours
msgid "{hours} hr"
msgid_plural "{hours} hrs"
msgstr[0] "{hours} hr"
msgstr[1] "{hours} hrs"

That our TMS changes to:

#. jsi18nicu={hours, plural, one {{hours} hr} other {{hours}
#. hrs}}&pluralize_on=hours
msgid "{hours} hr"
msgid_plural "{hours} hrs"
msgstr[0] ""
msgstr[1] ""
msgstr[2] ""

And cannot be parsed when doing lingui compile step.

Looking for feedback here, either we revert the changes for having ICU readable, or change the compiling/PO parser to combine the comments. FWIW I attempted the latter, and its fairly involved.

@garikkh kchh 💩 what if we will add a way to override serialize/deserialize function for this context comment? So you would be able to override and do whatever you want with it.

@timofei-iatsenko how do you see that working?

Are you talking about an option to override these two functions: https://github.com/lingui/js-lingui/pull/2347/files#diff-b1e7f700a5d1ca961f671624ce8d6d9c4bbee951afafa93523db9393d0afdfd9R319-R365

Would you want to take it one step further and handle ctxPrefix in this step too? And remove the "customICUPrefix" config option?

@garikkh yes i'm speaking about these two functions.

Would you want to take it one step further and handle ctxPrefix in this step too?

I also have been thinking about this, but it seems it would be hard to find this comment from all others comment, and if we will change that - this will be a breaking change. But the idea is OK, i will investigate is it possible technically or not.