Re: [xz-devel] xz-utils-man.po, French translation
Hello all, Am Sa., 8. Jan. 2022 um 18:15 Uhr schrieb Jean-Pierre Giraud : > > Package xz-utils > version 5.2.5-2 > > Hi, > Please find attached the french translation of the xz-utils manpage done > by "bubu" and proofread by the debian-l10n-french mailing list contributors. > > I think that this new translation could be included in a future release. > The file is broken; due to some markup errors it produces only one of the manpages. See the attached patch. Lasse, besides the markup issues, both French and German translations are meanwhile incomplete and partially outdated. Please update po4a/xz-man.pot, and then consider to create a kind of "intermediate" tarball and send it to the TP robot, requesting a new TP domain for "xz-man". Best Regards, Mario diff Description: Binary data
Re: [xz-devel] Status of man page translations?
Hello Lasse, Am So., 11. Apr. 2021 um 20:48 Uhr schrieb Lasse Collin : > > On 2021-04-04 Mario Blättermann wrote: > > But what ist the blocker which still prevents you from creating an > > intermediate tarball, send it to the TP coordinator and tell him to > > create a new domain named "xz-man"? > > I suppose I had forgotten it. If there were other reasons, I have > forgotten them too. Sorry. > > I suppose I can just submit a snapshot from the master branch. > xz-man.pot is compatible with v5.2 for now. xz.pot isn't compatible > between the branches though but if 5.2.6 is needed (impossible to know > now) maybe it's not that bad: > > The command line tool translations in v5.2 have strings that are > difficult to get right. The master branch has such strings too but not > as many. For the 5.2.5 release, many translations didn't pass basic > quality control due to these strings. Some translators (individuals or > teams) replied to my emails about suggested white-space corrections, > some didn't. Thus multiple translations were omitted from 5.2.5. With > this background I feel that if 5.2.6 is needed I won't consider any > *new* xz.po files for it anyway; new xz-man.po languages would be fine. > OK, good idea. I am curious to see when the first new translations will arrive :) Best Regards, Mario
[xz-devel] Status of man page translations?
Hello, in the Git repo of xz, we have the Autotools stack for man page translations for more than a year. The German versions are already shipped with v5.2.5. But what ist the blocker which still prevents you from creating an intermediate tarball, send it to the TP coordinator and tell him to create a new domain named "xz-man"? If nobody knows that the man pages are translatable, we will never get other than the German ones. Best Regards, Mario
Re: [xz-devel] Internationalization of man pages
Hm, forgot the attachment … Am Fr., 14. Feb. 2020 um 18:55 Uhr schrieb Mario Blättermann : > > Hello Lasse. > > Am Mi., 12. Feb. 2020 um 19:05 Uhr schrieb Lasse Collin > : > > > > On 2020-02-12 Mario Blättermann wrote: > > > Lasse Collin schrieb am Fr., 7. Feb. 2020, > > > 15:32: > > > > - po4a is never needed when building from a release tarball. > > > > > > This means, distribution packagers don't have to bother with po4a, > > > and the translated man pages will be installed automatically (unless > > > DISABLE_NLS) is set...? > > > > Exactly. > > > > > > The extra po4a options like unknown_macros=untranslated aren't > > > > needed in XZ Utils. > > > > > > Not for now, but with this options it is better because po4a changes > > > its behavior from time to time. Keeping the options would be safer. > > > > Hmmm, I don't know what kind of behavior changes po4a may have (or has > > had), > > In fact, it's the standard set of options which we use in > manpages-l10n to cover all imaginable problems and peculiarities in > Groff and Mdoc code. If you are sure you don't need these options, > just omit them. > > > so I may be missing something important. My thinking was: > > > > - groff_code=verbatim affects .de, .ie, and .if. These must be > > avoided anyway so getting an error from these is a good thing. > > > > - unknown_macros=untranslated: I hope that once po4a understands a > > macro, future versions will understand it too. Since there are no > > macros unknown to po4a now, I would like to get an error if I added > > such a macro. > > > > - untranslated="a.RE,\|": I don't understand this. It sounds like > > that certain macros shouldn't be translated but it made no > > difference with xz man pages. So perhaps it was useful where this > > line was copied. > > > > I can understand if unknown_macros=untranslated is needed for > > compatibility with old po4a versions, so it can be added if needed, > > although I would prefer the default pedantic behavior myself. > > > > > > - README wasn't updated yet to mention that man pages can be > > > > translated. > > > > > > After the new TP domain has been created (see below), you should add > > > a hint there. > > > > I will. > > > > > The German translation wasn't committed yet as po.de says this: > > > > > > > > This file is distributed under the same license as the > > > > manpages-de package. > > > > > > > > Which hopefully is trivial to change. :-) > > > > > > No problem, as the one and only author of the translation, I can > > > change the license to whatever you want. > > > > The original is public domain so that is somewhat preferred. If you > > prefer a permissive license it's OK to me, it just needs to be > > mentioned in the file COPYING too. Man page translation is a large > > amount of work after all. > > > I've created a new pot file and merged with the existing translation. > The result is attached. > > > > > If you wish the German man page translation to be part of 5.2.5, it > > > > could be good to test that "make DESTDIR=something install" also > > > > works on something else than GNU/Linux (the scripting for those > > > > details is ugly). The test should be done so that there are > > > > translated man pages available in the po4a/man directory, e.g. by > > > > using de.po from the first post of this thread. > > > > > > I will test it next weekend, but I only use GNU/Linux, I don't have MS > > > Windows, BSD, macOS or anything else. > > > > Thanks. While testing on GNU/Linux is useful still, trying on some *BSD > > or other POSIX system would be needed in case the makefile or shell > > scripting has portability issues. Perhaps someone else can try it. > > > > It should work fine even when --program-prefix=foo- or such configure > > options are used to get foo-xz, foo-unxz and so on. "make > > DESTDIR=something uninstall" should work too, although I guess the > > uninstall part is practically never needed. > > > > The uninstall code can remove more files than the install part > > installs: if the package included German xz.1 but not German xzdec.1, > > the uninstall target will still remove both if they exist. It's a minor > > bug that I think is OK to leave unfixed. &g
Re: [xz-devel] Internationalization of man pages
Hello Lasse. Am Mi., 12. Feb. 2020 um 19:05 Uhr schrieb Lasse Collin : > > On 2020-02-12 Mario Blättermann wrote: > > Lasse Collin schrieb am Fr., 7. Feb. 2020, > > 15:32: > > > - po4a is never needed when building from a release tarball. > > > > This means, distribution packagers don't have to bother with po4a, > > and the translated man pages will be installed automatically (unless > > DISABLE_NLS) is set...? > > Exactly. > > > > The extra po4a options like unknown_macros=untranslated aren't > > > needed in XZ Utils. > > > > Not for now, but with this options it is better because po4a changes > > its behavior from time to time. Keeping the options would be safer. > > Hmmm, I don't know what kind of behavior changes po4a may have (or has > had), In fact, it's the standard set of options which we use in manpages-l10n to cover all imaginable problems and peculiarities in Groff and Mdoc code. If you are sure you don't need these options, just omit them. > so I may be missing something important. My thinking was: > > - groff_code=verbatim affects .de, .ie, and .if. These must be > avoided anyway so getting an error from these is a good thing. > > - unknown_macros=untranslated: I hope that once po4a understands a > macro, future versions will understand it too. Since there are no > macros unknown to po4a now, I would like to get an error if I added > such a macro. > > - untranslated="a.RE,\|": I don't understand this. It sounds like > that certain macros shouldn't be translated but it made no > difference with xz man pages. So perhaps it was useful where this > line was copied. > > I can understand if unknown_macros=untranslated is needed for > compatibility with old po4a versions, so it can be added if needed, > although I would prefer the default pedantic behavior myself. > > > > - README wasn't updated yet to mention that man pages can be > > > translated. > > > > After the new TP domain has been created (see below), you should add > > a hint there. > > I will. > > > The German translation wasn't committed yet as po.de says this: > > > > > > This file is distributed under the same license as the > > > manpages-de package. > > > > > > Which hopefully is trivial to change. :-) > > > > No problem, as the one and only author of the translation, I can > > change the license to whatever you want. > > The original is public domain so that is somewhat preferred. If you > prefer a permissive license it's OK to me, it just needs to be > mentioned in the file COPYING too. Man page translation is a large > amount of work after all. > I've created a new pot file and merged with the existing translation. The result is attached. > > > If you wish the German man page translation to be part of 5.2.5, it > > > could be good to test that "make DESTDIR=something install" also > > > works on something else than GNU/Linux (the scripting for those > > > details is ugly). The test should be done so that there are > > > translated man pages available in the po4a/man directory, e.g. by > > > using de.po from the first post of this thread. > > > > I will test it next weekend, but I only use GNU/Linux, I don't have MS > > Windows, BSD, macOS or anything else. > > Thanks. While testing on GNU/Linux is useful still, trying on some *BSD > or other POSIX system would be needed in case the makefile or shell > scripting has portability issues. Perhaps someone else can try it. > > It should work fine even when --program-prefix=foo- or such configure > options are used to get foo-xz, foo-unxz and so on. "make > DESTDIR=something uninstall" should work too, although I guess the > uninstall part is practically never needed. > > The uninstall code can remove more files than the install part > installs: if the package included German xz.1 but not German xzdec.1, > the uninstall target will still remove both if they exist. It's a minor > bug that I think is OK to leave unfixed. > This is only relevant in some odd cases when somebody installs into /usr/ which is only for the files from distribution packages. Then it could happen that a file vanishes, which actually belongs to the manpages-de package. Well, it's some kind of undesired behaviour, but users should normally know that they must not install anything in /usr/ manually. Best Regards, Mario > > BTW, what about to create a pre-release tarball which contains an > > up-to-date *.pot file for the man pages and send it to the TP > > coordinator? > > For 5.2.5, the no
Re: [xz-devel] Internationalization of man pages
Hello Lasse, Lasse Collin schrieb am Fr., 7. Feb. 2020, 15:32: Hello! It's been a few months of silence but in the past two weeks have finally been able get something done in XZ Utils. I have committed support for translated man pages. Notes: - po4a is never needed when building from a release tarball. This means, distribution packagers don't have to bother with po4a, and the translated man pages will be installed automatically (unless DISABLE_NLS) is set...? - po4a is needed to build xz.git if one wants translated man pages. If po4a is missing, building will still work normally without translated man pages. - po4a/xz-man.pot, po4a/*.po, and the translated output in po4a/man/$lang are updated by running po4a/update-po. It is only run automatically by autogen.sh and "make mydist" (which I use to create the release tarballs). Running "make" never runs po4a/update-po. - To add a new translation, see the comment in po4a/po4a.conf. The extra po4a options like unknown_macros=untranslated aren't needed in XZ Utils. Not for now, but with this options it is better because po4a changes its behavior from time to time. Keeping the options would be safer. - It is OK if only some man pages are available for a language. Symlinks like unxz.1 -> xz.1 are created if and only if the target man page exists for the language. Yes, depending on the translation teams it can happen that a previously translated man page doesn't get built anymore because the translation doesn't reach the 80% threshold for po4a (after the original text has changed and nobody has completed the translation again). - The translated man pages aren't installed if --disable-nls is used. - README wasn't updated yet to mention that man pages can be translated. After the new TP domain has been created (see below), you should add a hint there. The German translation wasn't committed yet as po.de says this: This file is distributed under the same license as the manpages-de package. Which hopefully is trivial to change. :-) No problem, as the one and only author of the translation, I can change the license to whatever you want. The v5.2 branch should be very close to what XZ Utils 5.2.5 release will look like. The mess with new/updated translations needs to be sorted out to some extent, and then I can write NEWS and release a new version. If you wish the German man page translation to be part of 5.2.5, it could be good to test that "make DESTDIR=something install" also works on something else than GNU/Linux (the scripting for those details is ugly). The test should be done so that there are translated man pages available in the po4a/man directory, e.g. by using de.po from the first post of this thread. I will test it next weekend, but I only use GNU/Linux, I don't have MS Windows, BSD, macOS or anything else. BTW, what about to create a pre-release tarball which contains an up-to-date *.pot file for the man pages and send it to the TP coordinator? Maybe some other translators are interested in to provide localized man pages for xz... And moreover, maybe there are some changes since I've worked on the German translation? Not in the content itself, but sometimes newer versions of po4a introduce some other formatting. But regarding new translations: don't expect too much. It's a big chunk, and usually there are only a few people who are willing to translate man pages. I think Yuri Chornoivan (Ukrainian) and Rafael Fontenelle (Brazilian Portuguese) will soon start with, but for other languages, who knows... You don't have to wait a long time for new translations; as a rule of thumb, you can sync the po files from TP with your Git two weeks after publishing the pre-release tarball. And if new po files come in somewhat later, they are a good basis for the next release of xz. Best Regards, Mario
Re: [xz-devel] Internationalization of man pages
Hello Lasse, Am Fr., 28. Juni 2019 um 13:02 Uhr schrieb Lasse Collin : > > On 2019-06-26 Lasse Collin wrote: > > The overlong lines in --help simply should be fixed by the > > translators. In the near future xz won't have auto-wrap support for > > --help strings. > > I will reconsider this. It might be less painful to wrap multibyte > strings in portable C than I had assumed (excluding languages that don't > use spaces). So perhaps there might be some support for auto-wrapped > --help in the near future (but not in 5.2.5) after all. I try to get > back to this next week. > Let me summarize what I think about the next versions: Some new UI translations have arrived which would justify a bugfix release v5.2.5. All other things (re-wrapping the critical strings and man page translations) should wait until the master branch is ready for a new release (v5.4). Best Regards, Mario
[xz-devel] Internationalization of man pages
Hello Lasse, I've created a framework for the internationalization of man pages. It works as follows: As a prerequisite, the po4a tools are needed, see [1]. See the attached patch: The script create-translation-template.sh updates the translation template named xz-man.pot from all man pages in the subdirectories of src/ (currently it contains 638 gettext messages). A German translation (de.po) is already included. Other po files (which will hopefully arrive in the future) also need to be placed in src/, and the language code needs to be added in the [po4a_langs] line in po4a.conf. Then run the script create-translated-manpages.sh (or simply "po4a po4a.conf") to create the translated man pages. The Groff files will be placed in the subdirectories of src/, where the English man pages reside. If needed, the storage location can be changed in po4a.conf. Unfortunately, I have no experience with GNU Autotools, I'm just a translator, and no more than that. I don't know how to integrate the contents of my scripts with "configure" and the existing m4 macros. Once it works, xz needs a second translation domain at GNU TP. BTW, first I tried to submit my changes via a merge request at Github [2], because I thought it's an official mirror owned by you. But it isn't, and the owner explained to me that all his changes get overwritten by the mirroring script, and recommended me to contact you directly. Obviously he doesn't understand how real mirroring works … [1] https://po4a.org/index.php [2] https://github.com/xz-mirror/xz Best Regards, Mario patch.xz Description: application/xz
Re: [xz-devel] Re: XZ translations
Hello Anna, Am Freitag, 1. März 2019, 15:40:53 CET schrieb Anna Henningsen: > I’m happy to continue providing translations for German, or to pass that > on to somebody else/be part of a group of people who manage German > translations. > > Best, > – Anna OK, nice to know. XZ now could be added now to the TP. @Benno, once the new domain has been created, please add Anna Henningsen to the German team and assign her to XZ. Best Regards, Mario > > On 01.03.19 11:58, Mario Blättermann wrote: > > Am Donnerstag, 28. Februar 2019, 17:40:54 CET schrieb Adrien Nader: > >> On Thu, Feb 28, 2019, Benno Schulenberg wrote: > >>> Op 27-02-19 om 22:14 schreef Adrien Nader: > >>>> I'd like to continue to work on the translations but I severely lack > >>>> time for that. As such the best option is probably something where the > >>>> translation is handled by a group or by someone else and where I am able > >>>> to contribute (if time permits). > >>> Okay. I think it will be best that I add you to the French team (if and > >>> when XZ is added to the TP), an not assign XZ to anyone, so that any team > >>> member can make uploads for it, so that people who are interested in > >>> translating XZ to French can collaborate on it. > >> Souds good to me. :) > >> > > Sounds also good to me. Then let's wait for the answer from the last German > > translator. If there's no response within a reasonable time frame, let's say > > one week, we could go ahead with establishing a new domain for XZ at TP. > > > > Best Regards, > > Mario > > > > > > > > > > > >
[xz-devel] Re: XZ translations
Am Donnerstag, 28. Februar 2019, 17:40:54 CET schrieb Adrien Nader: > On Thu, Feb 28, 2019, Benno Schulenberg wrote: > > > > Op 27-02-19 om 22:14 schreef Adrien Nader: > > > I'd like to continue to work on the translations but I severely lack > > > time for that. As such the best option is probably something where the > > > translation is handled by a group or by someone else and where I am able > > > to contribute (if time permits). > > > > Okay. I think it will be best that I add you to the French team (if and > > when XZ is added to the TP), an not assign XZ to anyone, so that any team > > member can make uploads for it, so that people who are interested in > > translating XZ to French can collaborate on it. > > Souds good to me. :) > Sounds also good to me. Then let's wait for the answer from the last German translator. If there's no response within a reasonable time frame, let's say one week, we could go ahead with establishing a new domain for XZ at TP. Best Regards, Mario
[xz-devel] XZ translations
Hello, you are recognized as the last translator of XZ. The XZ project will probably host its translation files at the GNU Translation Project in the nearest future. Most of the current translators are already members there, but if we move de.po and fr.po to the TP, then of course we have to ask the other translators how to continue. There are some options: In case you are no longer willing to work on your translation, the appropriate TP team will find someone who picks it up. For the German translation, I could do this. If you want to continue on your translation, you should become a member of the TP. This is quite simple, just contact the team [1][2], the coordinator will give you further instructions. As the last option, your translation could be handled externally, means outside the TP workflow. You won't get informed about updated po files, upcoming releases, string freezes and so on. This is inconvenient for you and for the developers, because they have to maintain two channels for incoming translations. Anyway, it's your choice. Let us know about your decision soon. [1] http://translationproject.org/team/de.html [2] http://translationproject.org/team/fr.html Best Regards, Mario Blättermann (Coordinator of the German TP team)
Re: [xz-devel] Translation platform for XZ ?
Hello, Am Donnerstag, 21. Februar 2019, 18:38:06 CET schrieb Lasse Collin: > Hello! > > On 2019-02-17 Mario Blättermann wrote: > > It would be nice if xz would be integrated into a global translation > > platform. > > Benno Schulenberg asked me about this in 2016. I didn't want to think > about it at that moment and then it was forgotten. :-/ Let's try again > now. > He's CCed from now on. > > Once you are planning a new release, create a pre-release tarball two > > weeks before. Update the translation template (*.pot) and send it to > > the TP coordinator. He will merge this new template with the existing > > po files and send these to the teams (even to that teams which still > > haven't submitted a translation for xz). > > The instructions to the package maintainers tell to send an URL to a > source package instead of just sending a POT file. I suppose the URL > method is the right way. Having the whole package available for testing > is important. > Yes, of course, I meant a tarball, not a naked pot file. > > Two weeks later, you pull the updated po files back from TP and make > > your release. That's all, and for more convenience, it can be simply > > scripted. > > I worry that it's not that simple. My experience is that I need to look > through the translations because most have had some errors in aligning > columns in --help and --list outputs. In some cases it has taken > several tries until a translator has gotten it correctly done. > > There is debug/translation.bash to see the translations in action, and > there are instructions in README section 4. Multiple translators having > similar problems suggests that there's a problem in my code or > instructions, but I don't know how to improve. > In some translations, the --help output is split into two gettext messages: the option itself and the corresponding description. This way, translators don't have to bother with indentations, tab widths and so on. But this behavior I haven't found very often. Unfortunately, I don't have any coding skills, that's why I won't be able to help you. > I wonder should a few experienced translators look at this first so > that possible problems at my side can be fixed. It doesn't sound great > if I get 30 new translations and 25 need similar fixes and I need to > explain them to each translator separately. > Once a new translation arrives (assuming the TP robot sends it to this list) I will have a look at it. > From Benno Schulenberg I understood that most xz translators are already > part of TP (German and French were/are not). This needs to be sorted > out too, I guess. I suppose it would be convenient if all translations > were handled via TP (no external translations). > > There hasn't been much going on in the XZ Utils project recently. > Translating the latest stable release 5.2.4 would be a good start. The > next bug fix release 5.2.5 will probably have no changes in the > translatable strings. Would it be good to first figure out how the > translations by non-TP people will be handled and then submit 5.2.4 to > be translated (or submit to a small subgroup to find out if something > needs to be fixed at xz side first)? > > Well, it is possible to exclude some (already existing) po files from the TP workflow, but this is not very convenient. We should try to move all po files to the TP. The German translation is almost nine years old, who knows whether the nameless translator (he has only added his mail address) is still willing to continue on it? I will ask him and the French translator (CCing this list and Benno) whether they want to continue on the po files, and if yes, within the TP or externally. The other translations come from well-known members of the TP teams. In case of the German translation, it is well polished in terms of indentations of the --help output and punctuation. But this is not all a good translation needs: We need a consistent use of terms, and it should follow the syntax and grammar conventions of the translation teams (GNU TP, Gnome, Debian, Ubuntu etc.), which are actually independent from each other, but maintain similar dictionaries and regulations. I'm the coordinator of the German TP team, and I would welcome to have the XZ translation maintenance in our team. Best Regards, Mario
