r-devel / translations

subsite for translations
https://contributor.r-project.org/translations/
Creative Commons Attribution 4.0 International
1 stars 3 forks source link

po files -- how important are the source line number comments `#: ....` ? #13

Closed mmaechler closed 1 year ago

mmaechler commented 1 year ago

A propos r-devel/translations#6 (mixed up po files): There are new .po files that I should commit before the Sprint starts -- for you guys to get from R-devel, i.e. the trunk svn repos or the github.com/r-devel/ mirror (which only* has the trunk, differently from https://github.com/wch/r-source/ which mirrors the full R svn repos).

Important question: Do the many #: .... comments in the file make any sense for you when working with weblate? If we would eliminate them the "diffs" between original *.po and its update would become orders of magnitude smaller, it seems.

MichaelChirico commented 1 year ago

I find those quite useful for debugging/ introspection, to the point where I wrote code for the R .pot files to get source references too:

https://github.com/MichaelChirico/potools/blob/05e873dade3e3d148af5dc4a5b0c5206e6e511b9/R/write_po_file.R#L389

As to the large diffs, @daroczig reported some success using this tool to reduce merge conflicts:

https://github.com/beck/git-po-merge

PS I just noticed I omitted that inconsistency from my list of R vs C inconsistencies:

https://bugs.r-project.org/show_bug.cgi?id=18121

daroczig commented 1 year ago

Thanks, @mmaechler!

Weblate is set up to pull from https://svn.r-project.org/R/ at least daily, and the new PO files should be picked up automatically.

But that issue you mentioned is indeed worrisome .. I will debug what might have happened.

Regarding the source line numbers: it can be useful to get more context about the string to be translated -- although I am not sure if most weblate users will find it super useful in the current weblate integration: it is printed in the sidebar, but it's not hyperlinked to e.g. the git clones for easier lookup. Actually, this is something we can improve at the Sprint (opened r-devel/translations#5 to track this).

One issue might be if the git clone is out of sync with weblate and line numbers are not pointing to the right place .. but I think that would be super rare, and overall better to have this feature.

Regarding the diffs: it's indeed taking up a lot of space, but not unmanageable on my end. If it becomes problematic either on R Core's or the weblate admins' end, we should definitely revisit :+1:

daroczig commented 1 year ago

An example case in src/library/grDevices/po/en_GB.po when there's a conflict due to an added (or removed) fuzzy flag in weblate and the line number reference updated in the upstream repo:

<<<<<<< HEAD
#: devPS.c:4464
#, c-format
=======
#: devPS.c:4462
#, c-format, fuzzy
>>>>>>> 0f7c01af9 (resolve conflict in src/library/grDevices/po/en_GB.po)
msgid "failed open converter to encoding '%s'"
msgstr "failed open converter to encoding '%s'"

This is annoying, as someone needs to manually resolve, but it's probably still worth the extra work.

mmaechler commented 1 year ago

I did commit new *.po 2-3 days ago on purpose, so you can work with the latest version (of the R sources). Almost verything we (R-core) do to create the po files is laid down in the sources themselves. Are you aware of that (and where)? Hopefully we can talk next week about where the procedures could/might be tuned.

I think I should close this for now, as I understood you said you did want the source file names + line number comments. ... even though the line numbers change much more often than the msgid (text to be translated).. or not?

daroczig commented 1 year ago

I did commit new *.po 2-3 days ago on purpose, so you can work with the latest version (of the R sources).

Thanks, @mmaechler!

Almost verything we (R-core) do to create the po files is laid down in the sources themselves. Are you aware of that (and where)?

Weblate uses the POT file to generate the PO file for a new language. But I'm very happy to discuss if we should have a custom workflow instead of that approach.

I think I should close this for now, as I understood you said you did want the source file names + line number comments.

Indeed, thank you! Yes, we prefer to keep the line numbers.