He revisado la traducción de GIMP cadena por cadena hace unos años.
Pero sólo revisé la rama máster. Pensé que los cambios llegarían a la versión estable pero no fue así. Supongo que se tratan como dos versiones independientes entre si.
Lo siento porque la gente ha estado conviviendo con algunos errores durante años.
La versión de GIMP 3 está a punto de llegar. Mejor tarde que nunca.
deepl.com translation:
I have reviewed the GIMP translation string by string a few years ago.
But I only reviewed the master branch. I thought the changes would make it to the stable version but they didn’t. I guess they are treated as two versions independent of each other.
I’m sorry because people have been living with some bugs for years.
GIMP 3 version is coming soon. Better late than never.
Yes, the gimp-2-10 and the master branch have their own, independent translations - their user interfaces differ, so that is pretty much the only way to do this.
The translation status can be seen here: https://l10n.gnome.org/module/gimp/
Is up to the translation team maintainer do a cherry pick. No GIMP fault.
I’m not trying to find any culprits.
I’ve compared both files using Visual Studio Code and manually homogenized the translations.
Both files contained different strings that weren’t present in the other. So they are essentially different files.
I’m not familiarized with git more than doing a few commits here and there. I wonder if I can cherry pick a commit even if a string doesn’t belong to that file. I don’t want to risk to corrupt a .po file if the strings doesn’t belong to that .pot template.
Correct me if I am wrong because I don’t have a deep knowledge in gettext either.
The culprits that I’m trying to find are actually pieces of code. I also don’t know what can be causing it and, considering how old the issue is, I understand the frustration.
The best that I could find was a recent discussion: 2.99.18: please update ALL .po files (#11456) · Issues · GNOME / GIMP · GitLab. But @jboerema and @ajonsson have more expertise here
I wonder if I can cherry pick a commit even if a string doesn’t belong to that file. I don’t want to risk to corrupt a .po file if the strings doesn’t belong to that .pot template.
I see you are active in Damned Lies, so just go through there and it will take care of most things for you. There’s always an amount of double work when working with multiple branches though.
Damned Lies runs “msgfmt -cv” on the po files before submitting to repository, so they should be safe. The times there has been problems has mostly been in documentation when there are translations that bring in broken xml.
D-L automatically comments out unused strings with #~ and put them in the end of the file. These comments are harmless.
To lessen manual work you might wan’t to test out running “msgcat” on po files for master and gimp-2-10 and choosing to keep master strings on clashes. Not something that I have done for a long time, so you’ll have to test for yourself.
I also don’t know what can be causing it and, considering how old the issue is, I understand the frustration.
I don’t think there is any bug here outside of some translation fixes that weren’t committed to gimp-2-10.
The best that I could find was a recent discussion: 2.99.18: please update ALL .po files (#11456) · Issues · GNOME / GIMP · GitLab . But @jboerema and @ajonsson have more expertise here
That bug is merely a way of decreasing size of compiled .mo files. As I understand it, old po files have no real harm even if they might add old strings to the bundled mo file. Old msgids are just not used in the program.
Thank you so much for the info. I will give it a try.
This is what I meant. No bugs here. Just sharing my thoughts with the community. If I find a bug I will report it on gitlab. Thanks everyone for your kind replies.
I’ve tested it and it is amazing.
msgcat --use-first gimp.po-ui.master.es.po gimp.po-ui.gimp-2-10.es.po -o gimp.po-ui.merged.es.po
This allows me to keep strings from the first file.
If I omit --use-first flag both strings are concatenated and marked as fuzzy. This is perfect so I can review them later.
Then I can push one file for both braches and unused strings will be commented out.