Re: [xz-devel] Translation platform for XZ ?
Hello! I'm sorry for the delay. On 2019-02-22 Mario Blättermann wrote: > Am Donnerstag, 21. Februar 2019, 18:38:06 CET schrieb Lasse Collin: > > 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. :-) The xz-devel list only allows subscribers to post, which you probably already noticed. This a bit inconvenient but it keeps spam away. I get the rejected messages in my inbox still. > > 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 think some GNU packages use "argp" for the --help output where the messages are split as you described. argp can be convenient and I understand why translators may like it too. On the other hand, raw strings give translators more control how --help is shown (e.g. they can change the column where the description starts for all messages) which might be useful in some (rare) cases. argp is not in POSIX. argp is availabe in gnulib so it isn't too hard to add it into a package. The gnulib implementation is under LGPLv3+. xz is public domain because LZMA SDK is; I didn't want to use a more restrictive license than the original compression code does. Thus I don't want to use argp in xz. (There is GNU getopt_long in xz but it's not a big problem because a compatible enough version is available on many OSes, including all BSDs.) Obviously argp isn't the only way to split the --help messages. I haven't searched for other ready-made solutions though because so far I haven't had much interest in this. A bit more off-topic but I post it here anyway in case someone finds it interesting or even has knowledge and energy to improve the relevant argp code: Splitting the strings in --help works perfectly only if the library is sophisticated enough. Things are simple in US-ASCII, ISO-8859-*, and such character sets, but nowadays UTF-8 is the most common. In UTF-8 a single Unicode code point can use 1-4 bytes and each code point may use 0, 1, or 2 columns in a terminal. If these things aren't handled properly, the --help output won't look perfect. I tested GNU tar --help under de_DE (ISO-8859-1) and de_DE.UTF-8. It think argp uses bytes to calculate string lengths and thus gets it wrong under UTF-8 locale: --group-map=DATEI DATEI benutzen, um GIDs und Namen der Besitzer abzubilden --mode=ÄNDERUNGEN den (symbolischen) Modus ÄNDERUNGEN für hinzugefügte Dateien erzwingen "den (symbolischen)" is misaligned because the Ä in ÄNDERUNGEN is two bytes and argp thinks it takes two columns of space, while in reality those two bytes use only one column. With ISO-8859-1 locale the alignment is correct. The same problem causes line-wrapping to happen too early. ISO-8859-1 version first (converted to UTF-8 for email), then UTF-8: --xattrs-include=MASKE das Einschluss-Muster für xattr-Schlüssel angeben --xattrs-include=MASKE das Einschluss-Muster für xattr-Schlüssel angeben -P, --absolute-names führende »/«-Zeichen in den Dateinamen erhalten -P, --absolute-names führende „/“-Zeichen in den Dateinamen erhalten These aren't translator's fault, but still make the translated program look slightly sloppy. > > 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. I'm not sure if I understood correctly. If you meant that the TP would send the ready-made translations to xz-devel, I guess it's a problem due to only subscribers being able to post to xz-devel. I had thought the translations could
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
Re: [xz-devel] Translation platform for XZ ?
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. > 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. > 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. 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. 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)? -- Lasse Collin | IRC: Larhzu @ IRCnet & Freenode
