Report extra PO plural forms without changing parse - #1324
Conversation
Sorry, something went wrong.
read_po dropped msgstr[N] entries past nplurals, so the num_plurals checker always saw a matching count on parsed catalogs.
|
This would change how Babel has parsed files for a decade. #1323 didn't yet include analysis as to what to do about the issue, just that it exists. |
Sorry, something went wrong.
|
Fair point — dropping extra msgstr[N] on read has been the parse behaviour for a long time, and #1323 only showed that the checker is a no-op after that, not what to do about it. I went this way because num_plurals already runs on Catalog objects, so extra forms have to survive read_po for the check to mean anything. Happy to close this if you'd rather keep the historical parse and treat extras only at check time, or leave the checker as-is. |
Sorry, something went wrong.
Keep the historical read_po truncation of msgstr[N] past nplurals, but count those dropped entries so num_plurals() can still report them. Co-authored-by: Cursor <cursoragent@cursor.com>
|
Pushed a follow-up that keeps the historical parse. read_po still drops msgstr[N] when N >= nplurals and still pads message.string to catalog.num_plurals, so catalogs and write_po look the same as they have for a decade. The extra entries are counted on message.discarded_plural_forms so num_plurals() can report them instead of always seeing a matching length after the drop. |
Sorry, something went wrong.
Fixes #1323.
read_po still drops msgstr[N] entries where N >= nplurals and pads message.string to catalog.num_plurals, same as it has for a decade. Extra forms are counted on message.discarded_plural_forms so num_plurals() can fail on a parsed catalog instead of always seeing a matching length.