In a nutshell, I convert the Grit files (grd+xtb) from upstream/trunk into gettext, feed that to lp, get a bunch of po files in return.
I then select one of the chromium branches (could be trunk for the dailies, or one of the dev/beta/stable channels),
take the corresponding template (grd file) and merge the strings extracted from the LPs po files with the upstream xtb file,
to finally produce patches, that i land in the packaging branch, and submit to upstream to close the loop.
So the lp export branch is only a pool of translated strings for me. msgid is not the key, the "#:" id is, that's why i'm impacted by obsolete strings. msgmerge could help, but i can also drop msgstr for which the msgid is not the expected one for a given id.
But that means those ids won't have a proper translation ever.
It seems to impact only the templates for which they are no associated po files in the import branch.
I'll think about msgmerge but i already have a lot of code for this grit<->gettext: bazaar. launchpad. net/~chromium- team/chromium- browser/ chromium- translations- tools.head/ annotate/ head:/chromium2 pot.py
http://
In a nutshell, I convert the Grit files (grd+xtb) from upstream/trunk into gettext, feed that to lp, get a bunch of po files in return.
I then select one of the chromium branches (could be trunk for the dailies, or one of the dev/beta/stable channels),
take the corresponding template (grd file) and merge the strings extracted from the LPs po files with the upstream xtb file,
to finally produce patches, that i land in the packaging branch, and submit to upstream to close the loop.
So the lp export branch is only a pool of translated strings for me. msgid is not the key, the "#:" id is, that's why i'm impacted by obsolete strings. msgmerge could help, but i can also drop msgstr for which the msgid is not the expected one for a given id.
But that means those ids won't have a proper translation ever.