Repository navigation
Conversation
…d_sfa.c The message "One vertex registered" is used in build_nat.c with the plural "%" PRId64 " vertices registered" and in build_sfa.c with "%d vertices registered". A .pot file keeps only one plural form per singular msgid, and xgettext keeps the first one it reads. The input file list comes from find, whose order is not stable, so the template flipped between the two forms from one update to the next. Each flip changed the msgid and made the existing translations fuzzy. Use the 64-bit form in build_sfa.c as well, casting the int counters, so all three call sites share one msgid_plural. Prepared with AI assistance (Claude Code); the root cause was found from the history of locale/templates/grasslibs.pot. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
The lists of files given to xgettext come from find, whose order depends on the filesystem and can differ between runners. When the same msgid is used with different plural forms, xgettext keeps the first one it reads, so the generated .pot files could change without any change in the code. Sort the lists with LC_ALL=C so that the order is the same everywhere. Prepared with AI assistance (Claude Code). Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
echoix
changed the title
echoix
changed the title
echoix
force-pushed
the
claude/prid-translation-churn-u8lrv1
branch
from
October 3, 2026 21:00
4a5b8d7 to
b562817
Compare
Co-authored-by: Nicklas Larsson <n_larsson@yahoo.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Stops
locale/templates/grasslibs.potfrom changing without any code change:libvector:build_sfa.cuses"%" PRId64 " vertices registered"(with a(grass_int64)cast) as the plural of "One vertex registered", likebuild_nat.c.locale:make potsorts itsxgettextinput file lists withLC_ALL=C sort.Motivation and context
"One vertex registered" is used with two different plural forms:
"%" PRId64 " vertices registered"inbuild_nat.cand"%d vertices registered"inbuild_sfa.c(twice). A.potfile keeps one plural form per msgid, andxgettextkeeps the first one it reads. The file lists come fromfind, whose order is not stable, so the template flips between the two forms. Each flip changes the msgid and marks the existing translations as fuzzy:The first commit removes this conflict. The second makes the order deterministic. The next
locale: Update translation filesPR may change entries once, then it should stay stable.CMake: no equivalent change is needed.
locale/CMakeLists.txtonly installs.mofiles ("TODO: implement update and creation"), somake potinlocale/Makefileis the only path that generates the.potfiles. If CMake gets.potgeneration later, its file lists need sorting too (e.g.list(SORT ...)).How has this been tested?
Locally, with GNU xgettext 0.21, running the same
xgettextoptions asmake poton the sorted file list and on the same list reversed:.pot, sorted vs reversed ordermain)%<PRId64>in one run and%din the otherThe modules, wxPython and scripts domains also give the same msgids in both orders. The only difference, in the modules domain, is the placement of three
#. GTCtranslator comments, which the sorted list makes deterministic.On my fork, I ran the
Periodic updateworkflow on this branch (update_pofalse). It built GRASS, ranmake potandmake verifysuccessfully, and opened a template-update PR against this branch. In that PR:grasslibs.potkeepsmsgid_plural "%<PRId64> vertices registered". The only changes are thebuild_sfa.cline numbers in the location comments, which moved with the edit, and the creation date.grassmods.potchanges only in the order and duplication of three#. GTCtranslator comments.grasswxpy.potchanges only in the creation date.Types of changes
Checklist
AI disclosure: the root cause was found and the changes prepared with Claude Code. I reviewed the diff.
🤖 Generated with Claude Code