[ f'up2 to rhl-devel; the starting point of this thread is available at http://www.fedora.us/pipermail/fedora-devel/2003-July/001756.html ]
hp@redhat.com (Havoc Pennington) writes:
On Thu, Jul 24, 2003 at 01:19:11AM +0200, Enrico Scholz wrote:
Other thoughts or comments?
Probably works for now (we've been doing it forever), but in the end the only right thing has to be that translations are part of the package being translated.
I see a problem in the maintenance of these translations. With the specspo approach, there is one big .po-file which is updated by the translators. When making the translations a part of the package, there will be either thousands of small .po-files on the distribution side (Fedora, Red Hat) or the package author has to maintain his .po files himself.
IMHO, the latter option will not work because this will result in a maintainance nightmare: since there are not enough translators, every translator has to look after several packages, has to communicate with the author and the author has to release packages with updated translations very often. And this for every language...
So, there stays only the thousands of small .po-files case where the translator has to choose one of them. Clicking hundreds of time in the browser to download the files sounds very annoying and error-prone to me.
Sure, you can hide this complexity with tools but such tools must be written first and it will need a lot of work to make them as powerful like the current solutions (e.g. the Emacs po-mode).
Another advantage of the big .po file is, that common strings (e.g. group-names) need do be translated once.
Say you are using redhat-config-packages or another package tool. You see a list of packages. You should see nice user friendly names of those packages in your own language
Ok; but I do not think that this is a matter of translations. To make this possible, a new rpm-tag (e.g. 'LongName:' or 'ShortSummary:') which defaults to the value of 'Name:' must be created. This new tag can be added to the fields going to be translated.
But I think, only a few packages will profit from this; e.g. consider the 'docbook-style-*' packages. What will you use for 'LongName:'? When using e.g. _("docbook tools") the package-tool will present dozens of _("docbook tools") and user is forced to enable either the raw-view or to look at 'Summary:' to see which package it is.
Also you want translated descriptions of course.
I see no way to reliably do this using specspo. You have to somehow bundle the translations into the RPM package, and also install them when the RPM is installed.
You are right; specpo has disadvantages. E.g. you will have to download the several mebibytes sized package for every small change in the translation. There is a time-gap between package- and specspo-release also.
Otherwise mixing packages from different sources (including different OS versions) *will* break.
IMHO, this is not a big problem. The average user (who wants/needs translations), will use the big repositories (the upcoming Red Hat Linux Project, Fedora, Freshrpms, ...) which can provide their specspo-packages.
There is an issue with rpm that is not easy to "register" such packages; but for now, this can be solved with some %triggers and Jeff is open for ideas how it can be improved in "better" ways.
One approach would add a "PoFilesDir: foo" field to spec files, ...
Very interesting idea. Because I do not like decentralized maintainance of po-files, I would apply it in the following way:
* The build-hosts of the repositories which are maintaining the translations are "authoritative" regarding translations. "authoritative" means that there are global macros like
| %_i18n_update_pofiles 1 | %_i18n_translation_domain fedora-i18n
This i18n domain is maintained in the current way: there is a big .po file for every language, translators update it through cvs and release manager compiles it to a .mo-file.
* while doing 'rpmbuild -bs ...' on these hosts, the resulting srpm-package gets
- a tarball with *.po-files containing the trasnlated strings of the package - a tag like 'PoSources: <tarballname>'
non-authoritative hosts will not touch this tarball or tag.
* when doing 'rpmbuild --rebuild ...' for such a prepared srpm, the operations mentioned by you already (make update-po) will be executed and rpm creates translated headers by executing
| gettext(header[RPMTAG_SUMMARY/DESCRIPTION/...])
for every supported language.
'rpmbuild --rebuild' will not differ on authoritative and non-authoritative hosts.
Problems:
* it is not implemented yet
It might be nice if there were some way to add translation resource bundles to an RPM *after* building the RPM,
Yes; you will need to modify the headers (change localized language tags and increase release) and you will have to update the po-tarball. On the first glance, this does not look very complicated.
Enrico
On Thu, Jul 24, 2003 at 04:52:54PM +0200, Enrico Scholz wrote:
[ f'up2 to rhl-devel; the starting point of this thread is available at http://www.fedora.us/pipermail/fedora-devel/2003-July/001756.html ]
hp@redhat.com (Havoc Pennington) writes:
On Thu, Jul 24, 2003 at 01:19:11AM +0200, Enrico Scholz wrote:
Other thoughts or comments?
Probably works for now (we've been doing it forever), but in the end the only right thing has to be that translations are part of the package being translated.
I see a problem in the maintenance of these translations. With the specspo approach, there is one big .po-file which is updated by the translators. When making the translations a part of the package, there will be either thousands of small .po-files on the distribution side (Fedora, Red Hat) or the package author has to maintain his .po files himself.
Yup, one big file is much easier to hand to a per-locale translator.
And, even though I don't do i18n myself becuase I'm deprived of other languages, I suspect that one big file is easier on everyone involved than hundreds of 20 line files.
Is hundreds of teensy .po files doable? Sure, but there are many technical reasons not to do so.
The really important issue is that i18n is lots and lots of work from a team of people. IMHO, the work is best left to for-pay translators (and editors, hackers are not necessarily the best redactors) by commercial entities like Red Hat.
IMHO, the latter option will not work because this will result in a maintainance nightmare: since there are not enough translators, every translator has to look after several packages, has to communicate with the author and the author has to release packages with updated translations very often. And this for every language...
So, there stays only the thousands of small .po-files case where the translator has to choose one of them. Clicking hundreds of time in the browser to download the files sounds very annoying and error-prone to me.
Sure, you can hide this complexity with tools but such tools must be written first and it will need a lot of work to make them as powerful like the current solutions (e.g. the Emacs po-mode).
Another advantage of the big .po file is, that common strings (e.g. group-names) need do be translated once.
Thousands of teensy *.po files doesn't work? If so, we agree completely. Otherwise I'm confused by your words, as I see thousands of *.po files as a logistical nightmare that will just impede the process of l10n.
I'd suggest that someone who actually does (or has done) i18n translations for package Summary/Description/Group design the process, because the goal is to make it as easy as possible to complete and maintain the corpus.
Yes, no process design means that only ad hoc tools can be built.
Say you are using redhat-config-packages or another package tool. You see a list of packages. You should see nice user friendly names of those packages in your own language
Ok; but I do not think that this is a matter of translations. To make this possible, a new rpm-tag (e.g. 'LongName:' or 'ShortSummary:') which defaults to the value of 'Name:' must be created. This new tag can be added to the fields going to be translated.
But I think, only a few packages will profit from this; e.g. consider the 'docbook-style-*' packages. What will you use for 'LongName:'? When using e.g. _("docbook tools") the package-tool will present dozens of _("docbook tools") and user is forced to enable either the raw-view or to look at 'Summary:' to see which package it is.
This is a much nastier problem because:
a) there's a change of data type (i.e. RPM_STRING_TYPE -> RPM_I18NSTRING_TYPE involved, it's not just adding new text for RPMTAG_NAME or adding new LongName:/ShortName: tag. In fact, the creation of the data type was exactly the reason for a major incompatibility. Having personally survived (but barely) v2 -> v3 -> v4 -> v3 changes in rpm packaging, I wish not to go there ever again. I wasted 1 year of my life already discussing the ramifications of the value contained in byte 5 of an rpm package. Have at it, enjoy, I have no desire to go there again.
b) LongName: appears to have exactly the properties currently in %description; ditto ShortSummary: wrto Summary:; otherwise see c)
c) There are significant issues involved in attempting to do i18n on a database key like Name:. Yes, the value of Name: is displayed as output, and as output, is a candidate for translation. Writing a database layer that properly handles i18n'ified tags is way outside the scope of what I wish to attempt with rpmdb.
d) There's also the peripheral issue of the i18n name of the Name: tag, see "rpm -qi rpm" output. Should "Name:" or "Nom:" be displayed in LANG=fr_FR? My own opinion -- after having a long discussion with a member of the i18n team -- is that RPMTAG_NAME should be identified as a string in the C locale bacuase the value is havily used in, say, python constructs like N = h['name'], OTOH, the mechanism to do otherwise already exists if you disagree, see popt(3) aliases which are mostly gettext'ified and ready for translation. Note: only a single person has even attempted to look at the i18n problem wrto /usr/lib/rpm/rpmpopt-x.y.z afaik.)
e) rpm was written (and still uses) a ctype(3) parser because i18n was not even a consideration when rpm was written. The parser has broken several times becuase of i18n deployment, can/will break further if the tokens parsed (e.g. "Name:" used in error messages) are localized.
f) rpm is totally clueless about encodings, although reasonable deployments (because rpm is 8bit clean) might be attempted.
Also you want translated descriptions of course.
I see no way to reliably do this using specspo. You have to somehow bundle the translations into the RPM package, and also install them when the RPM is installed.
You are right; specpo has disadvantages. E.g. you will have to download the several mebibytes sized package for every small change in the translation. There is a time-gap between package- and specspo-release also.
My (and Red Hat's at the time) is specspo is great for distributions but bad for packages.
The major advantages for distros are a) single file encapsulation of large and changing set of text. b) uncoupling build from doc processes, they happen on different time scales, for different reasons, and mashing the two processes into one is a formidable task indeed. c) the potential for updating package translations after release.
The major disadvantage for 3rd party packages is that specspo has not been generalized into thousands of teensy *.po files. Certainly doable, will even attempt in rpm if/when I see a significant number of packagers, not distros, even attempting to translate package Summary/Description/Group.
Otherwise mixing packages from different sources (including different OS versions) *will* break.
IMHO, this is not a big problem. The average user (who wants/needs translations), will use the big repositories (the upcoming Red Hat Linux Project, Fedora, Freshrpms, ...) which can provide their specspo-packages.
There is an issue with rpm that is not easy to "register" such packages; but for now, this can be solved with some %triggers and Jeff is open for ideas how it can be improved in "better" ways.
Hmmm, hopefilly can be solved without %triggers, but yes I'm willing to try to accomodate.
One approach would add a "PoFilesDir: foo" field to spec files, ...
Very interesting idea. Because I do not like decentralized maintainance of po-files, I would apply it in the following way:
The build-hosts of the repositories which are maintaining the translations are "authoritative" regarding translations. "authoritative" means that there are global macros like
| %_i18n_update_pofiles 1 | %_i18n_translation_domain fedora-i18n
This i18n domain is maintained in the current way: there is a big .po file for every language, translators update it through cvs and release manager compiles it to a .mo-file.
while doing 'rpmbuild -bs ...' on these hosts, the resulting srpm-package gets
- a tarball with *.po-files containing the trasnlated strings of the package
- a tag like 'PoSources: <tarballname>'
non-authoritative hosts will not touch this tarball or tag.
when doing 'rpmbuild --rebuild ...' for such a prepared srpm, the operations mentioned by you already (make update-po) will be executed and rpm creates translated headers by executing
| gettext(header[RPMTAG_SUMMARY/DESCRIPTION/...])
for every supported language.
'rpmbuild --rebuild' will not differ on authoritative and non-authoritative hosts.
Problems:
- it is not implemented yet
I can certainly see ways to simplify and automate building distros that have packages with po sub-directories.
However, automation does not start with Let's add "PoFilesDir: foo" tag because ... there's far more to automation than parsing syntax (XML != automation).
Yeah there's tha "not implemented yet" problem isn't there ;-)
It might be nice if there were some way to add translation resource bundles to an RPM *after* building the RPM,
Yes; you will need to modify the headers (change localized language tags and increase release) and you will have to update the po-tarball. On the first glance, this does not look very complicated.
Been there, done that -- twice -- the process was called "drilling" and was nearly as painful as a root canal.
IMHO: i18n does not belong in rpm metadata anymore than i18n belongs in tar/cpio headers. Keep i18n out of packages, please.
73 de Jeff
Em Quinta, 24 de Julho de 2003 16:42, Jeff Johnson escreveu:
The really important issue is that i18n is lots and lots of work from a team of people. IMHO, the work is best left to for-pay translators (and editors, hackers are not necessarily the best redactors) by commercial entities like Red Hat.
My 2 person team has sucessfully translated all KDE releases since the 1.x days and Red Hat Linux from about 7 to European Portuguese. For some "smaller" countries like Portugal (10 million persons) you just can't wait that some day Red Hat will want to support a localized version.
The only problem we've faced so far with the specspo approach is that it's not regenerated enough times during a beta cicle; just look at the logs and see how many times it has been regenerated during the 8.0.x days. Volunteers work on their own free time so the earlier the specspo pot file is regenerated the bigger the change we'll find some time to update it. For example, it could use an update right now.
Pedro Morais KDE and Red Hat pt_PT i18n
On Thu, Jul 24, 2003 at 04:57:32PM +0100, Pedro Morais wrote:
Em Quinta, 24 de Julho de 2003 16:42, Jeff Johnson escreveu:
The really important issue is that i18n is lots and lots of work from a team of people. IMHO, the work is best left to for-pay translators (and editors, hackers are not necessarily the best redactors) by commercial entities like Red Hat.
My 2 person team has sucessfully translated all KDE releases since the 1.x days and Red Hat Linux from about 7 to European Portuguese. For some "smaller" countries like Portugal (10 million persons) you just can't wait that some day Red Hat will want to support a localized version.
The only problem we've faced so far with the specspo approach is that it's not regenerated enough times during a beta cicle; just look at the logs and see how many times it has been regenerated during the 8.0.x days. Volunteers work on their own free time so the earlier the specspo pot file is regenerated the bigger the change we'll find some time to update it. For example, it could use an update right now.
What needs "update"? New package additions not extracted into C.po all ready to go for you? Or do you mean that the just translated msgid's have changed in "fuzzy" ways.
Yes, package additions *require* addition to C.po in order for the translation process to work.
"Fuzzy" is even more complicated, ultimately depends on which of the following entities should "own" the text that appears in msgid's: a) upstream maintainers b) distro packagers/developers c) editors d) translators
Any of a) through d) is a possible/reasonable candidate for "ownership".
Choose one, and a reasonable process flow that efficiently gets the translations performed and distributed is quite easy.
OTOH, choose none or all of the above, and you will have a very complicated, difficult to administer, process, much like Red Hat's current process.
Lest there be any mistake: Red Hat has managed to do a quite reasonable job of getting translations for packages. Sure, not every locale is there, sure there's lots of glitches, but overall, I believe the process is pretty sound.
Disclaimer: I used to, but not for years, be responsible for Red Hat package i18n.
73 de Jeff
What needs "update"? New package additions not extracted into C.po all ready to go for you? Or do you mean that the just translated msgid's have changed in "fuzzy" ways.
Yes, package additions *require* addition to C.po in order for the translation process to work.
New package additions. Just take a look at the CVS log for (for example) specspo/pt.po. Somehow I can't believe that since 2003/02/24 the only thing that changed in the distro was the spamassassin summary. (2003/07/03). Was happens is that before the release there's a huge specspo update with lots and lots of packages. It'd be better if the file was updated more often.
"Fuzzy" is even more complicated, ultimately depends on which of the following entities should "own" the text that appears in msgid's: a) upstream maintainers b) distro packagers/developers c) editors d) translators
Uhm... Not the translators, I think. We own the text in the msgstr in our <locale>.po file.
Any of a) through d) is a possible/reasonable candidate for "ownership".
Choose one, and a reasonable process flow that efficiently gets the translations performed and distributed is quite easy.
I would choose b) or c), depending on who wrote the original spec file description. I guess that in rhl-project a) can now be equal to b).
Lest there be any mistake: Red Hat has managed to do a quite reasonable job of getting translations for packages. Sure, not every locale is there, sure there's lots of glitches, but overall, I believe the process is pretty sound.
Yes it is. It's just that if the specspo file got some attention earlier it would be much easier for the (voluntary) translators.
Pedro Morais
On Thu, Jul 24, 2003 at 11:42:26AM -0400, Jeff Johnson wrote:
Yup, one big file is much easier to hand to a per-locale translator.
This is trivial, it shouldn't dictate the overall approach. Ever heard of "cat" ? ;-)
a) there's a change of data type (i.e. RPM_STRING_TYPE -> RPM_I18NSTRING_TYPE involved, it's not just adding new text for RPMTAG_NAME or adding new LongName:/ShortName: tag. In fact, the creation of the data type was exactly the reason for a major incompatibility. Having personally survived (but barely) v2 -> v3 -> v4 -> v3 changes in rpm packaging, I wish not to go there ever again. I wasted 1 year of my life already discussing the ramifications of the value contained in byte 5 of an rpm package. Have at it, enjoy, I have no desire to go there again.
I wouldn't do it this way. Another suggestion is to have the gettext hash tables in the package file list (/usr/share/locale/LANG/translation-domain.mo)
The translation domain might be in the RPM header.
Then a tool such as redhat-config-packages, if the package is installed simply calls bindtextdomain (/usr/share/locale) and uses the gettext hash in-place; if the package is not installed it sucks the gettext hash out of the package and puts it somewhere temporary to use.
My (and Red Hat's at the time) is specspo is great for distributions but bad for packages.
specspo isn't much good for us either, really. It's always out of date and otherwise busted.
IMHO: i18n does not belong in rpm metadata anymore than i18n belongs in tar/cpio headers. Keep i18n out of packages, please.
i18n is already in the packages; if I install Gnumeric, then my Gnumeric has the translations with it.
It's just the RPM info itself that isn't translated.
An alternate solution is to copy the RPM header information (name, etc.) into a .desktop file that's included in the package, /usr/share/package-descriptions/gnumeric.desktop
This could be autogenerated in the spec file from %name etc.
There's no genuine difference between this and the above-mentioned approach with /usr/share/locale/LANG/translation-domain.mo, just a different flavor of the same.
You can't say translation just breaks if someone has packages from 3 versions of Red Hat, plus some 3rd party packages. Handling that case is a basic requirement we need to address at some point.
Havoc
On Thu, Jul 24, 2003 at 12:11:43PM -0400, Havoc Pennington wrote:
On Thu, Jul 24, 2003 at 11:42:26AM -0400, Jeff Johnson wrote:
Yup, one big file is much easier to hand to a per-locale translator.
This is trivial, it shouldn't dictate the overall approach. Ever heard of "cat" ? ;-)
Sure, but I've never heard of uncat. There are other technical issues, such as reducing the size of the corpus (and the translation work involved) by consolidating common strings into single msgid's.
Or maybe there's some option to cat that I've missed?
a) there's a change of data type (i.e. RPM_STRING_TYPE -> RPM_I18NSTRING_TYPE involved, it's not just adding new text for RPMTAG_NAME or adding new LongName:/ShortName: tag. In fact, the creation of the data type was exactly the reason for a major incompatibility. Having personally survived (but barely) v2 -> v3 -> v4 -> v3 changes in rpm packaging, I wish not to go there ever again. I wasted 1 year of my life already discussing the ramifications of the value contained in byte 5 of an rpm package. Have at it, enjoy, I have no desire to go there again.
I wouldn't do it this way. Another suggestion is to have the gettext hash tables in the package file list (/usr/share/locale/LANG/translation-domain.mo)
The translation domain might be in the RPM header.
Then a tool such as redhat-config-packages, if the package is installed simply calls bindtextdomain (/usr/share/locale) and uses the gettext hash in-place; if the package is not installed it sucks the gettext hash out of the package and puts it somewhere temporary to use.
I can/will discuss this process ad nauseum, but I am adamant (particularly if I have to do the work) in keeping i18n out of package headers.
I18n does not belong in package headers is my only non-negotiable stand. I'm quite willing to listen to any other approach.
My (and Red Hat's at the time) is specspo is great for distributions but bad for packages.
specspo isn't much good for us either, really. It's always out of date and otherwise busted.
You are confusing specspo and the process that creates it. And you have never attempted "drilling".
IMHO: i18n does not belong in rpm metadata anymore than i18n belongs in tar/cpio headers. Keep i18n out of packages, please.
i18n is already in the packages; if I install Gnumeric, then my Gnumeric has the translations with it.
It's just the RPM info itself that isn't translated.
Don't confuse summary/description/group with analogies for how other i18n text is handled.
The problem space is very very different wrto rpm summary/description/group.
An alternate solution is to copy the RPM header information (name, etc.) into a .desktop file that's included in the package, /usr/share/package-descriptions/gnumeric.desktop
This could be autogenerated in the spec file from %name etc.
There's no genuine difference between this and the above-mentioned approach with /usr/share/locale/LANG/translation-domain.mo, just a different flavor of the same.
You can't say translation just breaks if someone has packages from 3 versions of Red Hat, plus some 3rd party packages. Handling that case is a basic requirement we need to address at some point.
That sketchy process is fine by me, as the i18n is not in package metadata, nor does it need to be imho.
I can say similar things about Name:, Packager:, Distribution: tags, I don't believe that any of that information belongs in, (note I didn't say "with") rpm metadata either.
But let's not get our panties too twisted yet, the (or at least my) goal is to get the maximum amount of software in from of the maximum number of users in as useful a fashion as possible, and I'm quite sure we agree on that goal even if we differ on implementation details.
73 de Jeff
On Thu, Jul 24, 2003 at 12:30:38PM -0400, Jeff Johnson wrote:
Sure, but I've never heard of uncat. There are other technical issues, such as reducing the size of the corpus (and the translation work involved) by consolidating common strings into single msgid's.
Or maybe there's some option to cat that I've missed?
I'm pretty sure the utilities that come with gettext can do this kind of thing. (merge po files)
Unmerging is just a matter of scanning for msgid's found in a given package, it should be trivial.
I can/will discuss this process ad nauseum, but I am adamant (particularly if I have to do the work) in keeping i18n out of package headers.
I18n does not belong in package headers is my only non-negotiable stand. I'm quite willing to listen to any other approach.
Oh I could care less if it's in the headers or not ;-)
I just want it in the package somewhere, rather than having a "central registry" package with all the translations. Packages should be self-contained (well, other than dependencies, but I don't think "Requires: specspo = X.Y" would go over well).
Havoc
On Thu, Jul 24, 2003 at 02:22:41PM -0400, Havoc Pennington wrote:
Oh I could care less if it's in the headers or not ;-)
I just want it in the package somewhere, rather than having a "central registry" package with all the translations. Packages should be self-contained (well, other than dependencies, but I don't think "Requires: specspo = X.Y" would go over well).
s/it in/it with/ and we're on the same page. Otherwise, it's time to get the snake oil out and wrestle. Wheee!
73 de Jeff
On Thu, 2003-07-24 at 14:26, Jeff Johnson wrote:
On Thu, Jul 24, 2003 at 02:22:41PM -0400, Havoc Pennington wrote:
Oh I could care less if it's in the headers or not ;-)
I just want it in the package somewhere, rather than having a "central registry" package with all the translations. Packages should be self-contained (well, other than dependencies, but I don't think "Requires: specspo = X.Y" would go over well).
s/it in/it with/ and we're on the same page. Otherwise, it's time to get the snake oil out and wrestle. Wheee!
MUST.... STOP.... MENTAL... IMAGE... arggggggggggggggggggggh
-sv
On Thu, 2003-07-24 at 12:32, seth vidal wrote:
On Thu, 2003-07-24 at 14:26, Jeff Johnson wrote:
On Thu, Jul 24, 2003 at 02:22:41PM -0400, Havoc Pennington wrote:
Oh I could care less if it's in the headers or not ;-)
I just want it in the package somewhere, rather than having a "central
s/it in/it with/ and we're on the same page. Otherwise, it's time to get the snake oil out and wrestle. Wheee!
MUST.... STOP.... MENTAL... IMAGE... arggggggggggggggggggggh
Tickets for the snake oil match will be sold at ticketmaster. The event will be held at the collesium right before the SCO vs Lions match.
Havoc Pennington writes:
On Thu, Jul 24, 2003 at 12:30:38PM -0400, Jeff Johnson wrote:
Sure, but I've never heard of uncat. There are other technical issues, such as reducing the size of the corpus (and the translation work involved) by consolidating common strings into single msgid's.
Or maybe there's some option to cat that I've missed?
I'm pretty sure the utilities that come with gettext can do this kind of thing. (merge po files)
Exactly, "msgmerge <combined> <single>" would do that for you. Repeat for each "<single>".
Havoc Pennington writes:
I wouldn't do it this way. Another suggestion is to have the gettext hash tables in the package file list (/usr/share/locale/LANG/translation-domain.mo)
The translation domain might be in the RPM header.
Then a tool such as redhat-config-packages, if the package is installed simply calls bindtextdomain (/usr/share/locale) and uses the gettext hash in-place; if the package is not installed it sucks the gettext hash out of the package and puts it somewhere temporary to use.
I'm trying to follow this discussion, but I don't quite understand what you suggest here. Partly I'm confused about what is variables, and what is literal.
If we take an example: Swedish translations and coreutils. The translations of coreutils' own messages resides in /usr/share/locale/sv/LC_MESSAGES/coreutils.mo. What would be the file name of the file containing the Swedish translation of the %description of the RPM package coreutils? And what other translations would that file contain?
On Fri, Jul 25, 2003 at 01:33:40AM +0200, Göran Uddeborg wrote:
If we take an example: Swedish translations and coreutils. The translations of coreutils' own messages resides in /usr/share/locale/sv/LC_MESSAGES/coreutils.mo. What would be the file name of the file containing the Swedish translation of the %description of the RPM package coreutils? And what other translations would that file contain?
I didn't mean to try to address that in detail. You could do it several ways. Maybe rpm-coreutils-X.Y-Z.mo ?
Havoc
Havoc Pennington writes:
I didn't mean to try to address that in detail. You could do it several ways. Maybe rpm-coreutils-X.Y-Z.mo ?
Ok, so you mean a separate message catalog per package, containing the translations related to the package. That makes sense to me.
Now, let's see if I can imagine how this would be done.
Preparation for translation:
1. Descriptions, summaries, and group information are extracted from all SPEC files. Putting descriptions and summaries in the same po file probably makes sense, the group names could be collected in a separate po file if convenient. 2. This/these po files are made available for translation. (Talking of which, when will specspo appear in this cycle? :-) 3. As translations arrive, they are put in some dedicated hierarchy. Call this H. (/var/lib/rpm/locale/... maybe, I'm sure a nice macro could be used to define this. :-)
During package build:
1. Rpmbuild creates a pot file containing description, summary, and group for the package being built. 2. For each language defined in H, look for translations of the messages in the pot file made. This would be something like
msgmerge -C <file1> -C <file2> ... /dev/null <pot-file>
Where <fileN> are all translations found in H for this language. If the resulting file contains any translations, it is included in the package as the translations for that language.
When running things like "rpm -qi" or redhat-config-packages
1. When a description, summary, or group is to be displayed, a translation is sought by a call to dgettext() whith a domain name derived from the package being inspected.
Would this make sense? Is it approximately along the lines you meant? (To the extent you had them thought out.)
Would it be appropriate to put these package po files in some specific hierarchy, separate from /usr/share/locale? (And do a corresponding call to bindtextdomain() before calling dgettext().)
Is the needed information always available? Like, does rpm know enough in time to find the po files when quering a package file, for example?
How would one handle building single packages, not being part of a distribution? Maybe by having an RPM directive specifying a directory in the build tree to search for further message catalogs? Then the translations for this package would be part of the source of the package, which I guess would make sense.
Or am I missing too much here?
On Fri, Jul 25, 2003 at 11:26:42PM +0200, Göran Uddeborg wrote:
Havoc Pennington writes:
I didn't mean to try to address that in detail. You could do it several ways. Maybe rpm-coreutils-X.Y-Z.mo ?
Ok, so you mean a separate message catalog per package, containing the translations related to the package. That makes sense to me.
Now, let's see if I can imagine how this would be done.
Preparation for translation:
- Descriptions, summaries, and group information are extracted from all SPEC files. Putting descriptions and summaries in the same po file probably makes sense, the group names could be collected in a separate po file if convenient.
- This/these po files are made available for translation. (Talking of which, when will specspo appear in this cycle? :-)
- As translations arrive, they are put in some dedicated hierarchy. Call this H. (/var/lib/rpm/locale/... maybe, I'm sure a nice macro could be used to define this. :-)
During package build:
Rpmbuild creates a pot file containing description, summary, and group for the package being built.
For each language defined in H, look for translations of the messages in the pot file made. This would be something like
msgmerge -C <file1> -C <file2> ... /dev/null <pot-file>
Where <fileN> are all translations found in H for this language. If the resulting file contains any translations, it is included in the package as the translations for that language.
When running things like "rpm -qi" or redhat-config-packages
- When a description, summary, or group is to be displayed, a translation is sought by a call to dgettext() whith a domain name derived from the package being inspected.
The only difference from the current specspo implementation (which uses dgettext) is: you are moving the package derived retrieval key from the 2nd MSGID arg to the 1st DOMAINNAME arg without specifiying what is to replace MSGID.
If you are hoping to use the MSGID from package headers as the MSGID key, then your solution is inferior to the current specspo implementation because the Group/Summary/Description then *must* be built into packages.
Several attempts to compile those tags directly into package headers have all failed here at Red Hat.
So what specspo does instead is to use a two stage lookup using dgettext.
Here's the (simplified) sequence of operations for specspo: langval = getenv(language); setenv(language, "en_US", 1); domain = "redhat"; msgid = dgettext(domain, "rpm(Group)"); setenv(language, langval, 1); msgid = dgettext(domain, msgid);
Note that Using specspo maps msgid out of package metadata as well as msgstr.
Note also that domain is already being used for much what you propose.
There's absolutely nothing at all stopping anyone from adding a domain to the colon seperated set of domains in the macro %{_i18ndomains} and doing exactly what you propose. If there truly become thousands of 3rd party packagers, all clamoring for their own per-package domain, the current specspo scheme is quite sound, needs only a way to discover thousands of domains through configuration.
Would this make sense? Is it approximately along the lines you meant? (To the extent you had them thought out.)
Would it be appropriate to put these package po files in some specific hierarchy, separate from /usr/share/locale? (And do a corresponding call to bindtextdomain() before calling dgettext().)
Is the needed information always available? Like, does rpm know enough in time to find the po files when quering a package file, for example?
How would one handle building single packages, not being part of a distribution? Maybe by having an RPM directive specifying a directory in the build tree to search for further message catalogs? Then the translations for this package would be part of the source of the package, which I guess would make sense.
Or am I missing too much here?
You're missing several important points:
a) msgid's, not just msgstr's, need to be handled. msgid's are not necessarily constant, nor is there (or at least gas there been) sufficient time late in a release cycle to manage "make world" rebuilds to include i18n, too many things can break.
b) whatever organization you wish has to be as simple as possible to set up in an empty chroot, i.e. the environment in which anaconda runs during install.
c) the goal must be to have i18n tags in metadata, fetching from the payload is a costly decompression.
Sure your scheme makes sense, but is possibly different than what rpm has been doing since 6.2. There are consequences for having to support multiple schemes for the indefinite future, not the least of which is the complexity involved.
IMHO the apparent driving force for revisiting an already solved problem is the perceived need to accomodate 3rd party package group/summary/description.
Personally, I have yet to meet (or hear of) any single person who has even attempted the translation.
73 de Jeff
Jeff Johnson writes:
The only difference from the current specspo implementation (which uses dgettext) is: you are moving the package derived retrieval key from the 2nd MSGID arg to the 1st DOMAINNAME arg without specifiying what is to replace MSGID.
The specspo implementation creates one huge database of descriptions for all and only packages of one release. My intention was to try to envision a scheme, inspired by the ideas in Havoc's letters, where this was split up per package instead.
If you are hoping to use the MSGID from package headers as the MSGID key, then your solution is inferior to the current specspo implementation because the Group/Summary/Description then *must* be built into packages.
That was how I thought about it. But I guess it is not really critical. You could continue the current practice of using a po-file for a key-value lookup, and still have one po file per package as I suggested.
I haven't fully understood why it is such a good idea. I thougt gettext was designed to avoid having opaque keys, and instead use the English language message directly as the key. And this seems to go contrary to that, back to the catgets() inteface.
But again, this is not really the same issue.
There's absolutely nothing at all stopping anyone from adding a domain to the colon seperated set of domains in the macro %{_i18ndomains} and doing exactly what you propose.
But I want each package to have its own domain. There is no easy way to automatically add a domain to i18ndomains on package installation, and remove it on uninstall, is it?
You're missing several important points:
I'm sure I am.
a) msgid's, not just msgstr's, need to be handled. msgid's are not necessarily constant,
If I update specspo, it may result in that descriptions of already installed packages change or disappear. Is it this sense of "not ... constant" you refer to?
I consider that a bug. One of the bugs I'm trying to solve here.
If I do "rpm -qip xmms-1.2.7-1.i386.rpm", with specspo installed, I get a description not mentioning MP3. If I uninstall specspo, or change to locale C or so, I get the package's original description, mentioning MP3.
Similarily, if I to "rpm -qi mpg321" on a system which still has this package, but current specspo, I don't get the description translatied. There was a translation, but it is not part of current specspo.
In both cases, the messages, and translations of them, which existed at the time of package generation is better than the current situation. They ought to come and go with the package itself.
nor is there (or at least gas there been)sufficient time late in a release cycle to manage "make world" rebuilds to include i18n, too many things can break.
That could of course be a problem.
To me it seems it would be possible to freeze descriptions of the new packages earlier. Like already by now in the current cycle. And also make them available for translation at this time. Then they could be there when the final build is done.
But I realise I don't know the internals of these routines.
c) the goal must be to have i18n tags in metadata, fetching from the payload is a costly decompression.
I must have misunderstood something. In message 20030724114226.Q18401@devserv.devel.redhat.com you said:
IMHO: i18n does not belong in rpm metadata anymore than i18n belongs in tar/cpio headers. Keep i18n out of packages, please.
I understood that to mean that you did not want the translations in the metadata. So I tried to sketch things obeying that, putting them elsewhere.
But maybe I misunderstood this comment. If so, I guess one could try to extend the current "%description -l ...". As I understand it, this does become package metadata; at least it winds up in the Packages database file.
As you pointed out, this lacks coding information. Also, putting all translations in the spec file is not very convenient. They need to be fetched externally at build time. But if this is an acceptable method, these problems probably could be solved.
Sure your scheme makes sense, but is possibly different than what rpm has been doing since 6.2. There are consequences for having to support multiple schemes for the indefinite future, not the least of which is the complexity involved.
Point taken.
IMHO the apparent driving force for revisiting an already solved problem is the perceived need to accomodate 3rd party package group/summary/description.
Personally, I have yet to meet (or hear of) any single person who has even attempted the translation.
Are we talking about translations of descriptions at all? Or only through external po files?
I always include Swedish versions when I build packages of my own. (After rhcontrib.bero.org died, I've mostly circulated them among friends. Some could probably still be found out there; rpmfind found a stickers package for example.)
I may be uncommon doing this. But then again, including translations in the SPEC file is not very convenient. And is "%description -l" documented anywhere except for the change log and the source code? There is a chance not everybody is aware of the possibility. :-)
On Tue, Jul 29, 2003 at 11:39:47PM +0200, Göran Uddeborg wrote:
The specspo implementation creates one huge database of descriptions for all and only packages of one release. My intention was to try to envision a scheme, inspired by the ideas in Havoc's letters, where this was split up per package instead.
Jeff made the point to me in a hallway conversation that a more appropriate split might be "per translation team." At least I think he'd agree with that.
Havoc
On Tue, Jul 29, 2003 at 08:52:04PM -0400, Havoc Pennington wrote:
On Tue, Jul 29, 2003 at 11:39:47PM +0200, Göran Uddeborg wrote:
The specspo implementation creates one huge database of descriptions for all and only packages of one release. My intention was to try to envision a scheme, inspired by the ideas in Havoc's letters, where this was split up per package instead.
Jeff made the point to me in a hallway conversation that a more appropriate split might be "per translation team." At least I think he'd agree with that.
Good we appear to be moving to convergence ;-)
If the intent is to have one domain per-package, the current implementation already supports this. For example, suppose you want a single domain for package "foo". This is the current process to create:
a) configure the new translation domain in /etc/rpm/macros.specspo (or any of the zillions of places that a macro can be defined) %_i18ndomains redhat:foo
b) add the msgid text in the usual places within the en_US locale. Here's what needs to be there for %description: msgid: "foo(Description)" msgstr: "This is foo's description."
c) add the usual PO file in the usual places for domain "foo". Here's what needs to be there for the above: msgid: "This is foo's description." msgstr: "This is the translation of foo's description."
This mechanism is sufficiently general to support thousands of teensy per-package domains without changing anything.
Any wartlets, like linear search on domains, or abuse of en_US can be easily solved in the rpm implementation, not the package format, or rpmbuild process.
Any other solution, like compiling in msgid's into packages again again again, or adding new-fangled tags, is gonna cause trouble imho.
So what's wrong with the above?
73 de Jeff
Jeff Johnson writes:
If the intent is to have one domain per-package, the current implementation already supports this.
I start to feel, during this discussion, goal and implementation has become a bit confused. I'm surely guilty, starting my posts by an attempt to suggest an implementation of my interpretation of Havoc's suggestion.
I'll try to clarify MY goals.
As a RHL user I want
the description (etc.), including translations, come, change, and go with the package. I don't want them to be modified when a different, technically unrelated, package is modified.
Having one domain per package and including that domain with the package, is one way to implement that. Having all descriptions in the meta-data is another way. There are surely other ways.
As a packager of third party packages I want
an easy way to maintain the description, and to receive translations of it.
That was why I thought around having rpmbuild pick up translations at build time from po-files laying around. If I also am the author of the software I package, it would be convenient to put all messages from the program(s) proper and the spec file description in one po file and make that available for translation. (Doing some kind of "gettext" on the spec file.) If I package someone elses software, it would be more reasonable to provide a separate po file for translators.
Manually copying translations back and forth between po files and spec files is not very convenient, obviously.
As a translator of RHL descriptions (a.k.a. "specspo") I want
the descriptions be available in a format which is easy to translate and maintain.
The current specspo is fine for this! (It is huge, and took a long time to do. But that would not have been different with some other packaging.)
As a translator of other's third party packages I want
the same thing as for RHL packages, a convenient format.
Of course I would expect to get it individually for each package, and not collected together with other unrelated packages. But po files are good again.
That's several "I want"s. I'm not saying one solution should fullfill all, and I'm not at all saying they MUST be fullfilled before any other problem. But if one of them could be fulfilled, it would be better than none.
a) configure the new translation domain in /etc/rpm/macros.specspo (or any of the zillions of places that a macro can be defined) %_i18ndomains redhat:foo
Do you envisage some way to do this automatically on (un)installation of packages? So that each package can carry it's own translations? Or just a different default value coming with the same specspo package still carrying all translations? That's would be important given my first point above. And I'm not sure exactly what you are suggesting.
On Fri, Aug 01, 2003 at 12:22:30AM +0200, Göran Uddeborg wrote:
Jeff Johnson writes:
If the intent is to have one domain per-package, the current implementation already supports this.
I start to feel, during this discussion, goal and implementation has become a bit confused. I'm surely guilty, starting my posts by an attempt to suggest an implementation of my interpretation of Havoc's suggestion.
Yup, add LSB packaging standard, very hard to not be confused.
I'll try to clarify MY goals.
As a RHL user I want
the description (etc.), including translations, come, change, and go with the package. I don't want them to be modified when a different, technically unrelated, package is modified.
Having one domain per package and including that domain with the package, is one way to implement that. Having all descriptions in the meta-data is another way. There are surely other ways.
All agreed, although "domain" is dangerously close to implementation.
As a packager of third party packages I want
an easy way to maintain the description, and to receive translations of it.
That was why I thought around having rpmbuild pick up translations at build time from po-files laying around. If I also am the author of the software I package, it would be convenient to put all messages from the program(s) proper and the spec file description in one po file and make that available for translation. (Doing some kind of "gettext" on the spec file.) If I package someone elses software, it would be more reasonable to provide a separate po file for translators.
Manually copying translations back and forth between po files and spec files is not very convenient, obviously.
Also agreed, and noted that you (and Havoc) are also interested in the general problem, not just i18n for description/summary/group.
I am mainly concerned about rpm package format changes, as retrofitting Yet Another Solution (the next will be like my 5th attempt to get it right, sigh) into package format is not fun at all.
Other than package format changes -- a topic that I'm no longer sane about -- I'm perfectly prepared to admit that rpm currently serves neither of your goals above well, and would like to do something better.
As a translator of RHL descriptions (a.k.a. "specspo") I want
the descriptions be available in a format which is easy to translate and maintain.
Yup, must be *.po, and I'll wave my hands about "implementation".
The current specspo is fine for this! (It is huge, and took a long time to do. But that would not have been different with some other packaging.)
I'll take that as complement, just trying to do my job. Truly, what makes specspo possible -- msghack -- is a very, very tortured implementation. And implementation credit is gafton, idea was/is mine.
As a translator of other's third party packages I want
the same thing as for RHL packages, a convenient format.
Of course I would expect to get it individually for each package, and not collected together with other unrelated packages. But po files are good again.
We agree that *.po is only conceivable (i.e. works/useful/adequate/your_criteria_here)?
(implementation aside) Hacking xgettext quite possible. xgettext already knows about C and shell syntax, not hard at all to teach xgettext about *.rpm, no parsing needed. I do shudder when considering a dependency gettext -> librpm*.so, but a parallel implementation is quite sensible and doable. In fact, suggested to Drepper years ago, but there was little need.
That's several "I want"s. I'm not saying one solution should fullfill all, and I'm not at all saying they MUST be fullfilled before any other problem. But if one of them could be fulfilled, it would be better than none.
I want the same things as you, with the further constraint: I want what you want. Nothing you have suggested is unreasonable or outlandish imho.
a) configure the new translation domain in /etc/rpm/macros.specspo (or any of the zillions of places that a macro can be defined) %_i18ndomains redhat:foo
Do you envisage some way to do this automatically on (un)installation of packages? So that each package can carry it's own translations? Or just a different default value coming with the same specspo package still carrying all translations? That's would be important given my first point above. And I'm not sure exactly what you are suggesting.
Sure, macros are easily changed into something more robust. In fact, that's what macros were intended for, a lightweight and cheap, proof-of-concept, prototyping mechanism.
Note carefully that doing a) differently involves changing the rpm implementation, not the rpm package format, my only concern.
Note also that additions, like adding a domain tag to metadata, are quite doable, as long as the legacy issues of fallback can be addressed in the rpm implementation adequately.
Replacing and/or changing existing implementation is what gives me hives.
73 de Jeff
Jeff Johnson writes:
On Fri, Aug 01, 2003 at 12:22:30AM +0200, Göran Uddeborg wrote:
Jeff Johnson writes: As a RHL user I want
the description (etc.), including translations, come, change, and go with the package. I don't want them to be modified when a different, technically unrelated, package is modified.
Having one domain per package and including that domain with the package, is one way to implement that. Having all descriptions in the meta-data is another way. There are surely other ways.
All agreed, although "domain" is dangerously close to implementation.
"Domain" is certainly implementation.
I meant the FIRST paragraph to be a clean requirement specification. The SECOND was meant to show how the implementation I had suggested in earlier mails could meet the specification.
You can't be too clear, I guess. :-)
I am mainly concerned about rpm package format changes, as retrofitting Yet Another Solution (the next will be like my 5th attempt to get it right, sigh) into package format is not fun at all.
Quite reasonable, that is definitely constraints which should be taken into account.
The current specspo is fine for this! [...]
I'll take that as complement, [...]
Please do!
We agree that *.po is only conceivable (i.e. works/useful/adequate/your_criteria_here)?
What about: "*.po is a good implementation meeting my requirements as a translator, and I am not aware of any other format/toolset which also does".
It is true, and it doesn't actually specify an implementation. :-)
I'm not a purist always keeping specification and implementation strictly apart. In this case I felt the discussion becoming confused, so I wanted to clarify, that was all.
On Tue, Jul 29, 2003 at 11:39:47PM +0200, Göran Uddeborg wrote:
Jeff Johnson writes:
The only difference from the current specspo implementation (which uses dgettext) is: you are moving the package derived retrieval key from the 2nd MSGID arg to the 1st DOMAINNAME arg without specifiying what is to replace MSGID.
The specspo implementation creates one huge database of descriptions for all and only packages of one release. My intention was to try to envision a scheme, inspired by the ideas in Havoc's letters, where this was split up per package instead.
(under seperate cover)
If you are hoping to use the MSGID from package headers as the MSGID key, then your solution is inferior to the current specspo implementation because the Group/Summary/Description then *must* be built into packages.
That was how I thought about it. But I guess it is not really critical. You could continue the current practice of using a po-file for a key-value lookup, and still have one po file per package as I suggested.
I haven't fully understood why it is such a good idea. I thougt gettext was designed to avoid having opaque keys, and instead use the English language message directly as the key. And this seems to go contrary to that, back to the catgets() inteface.
The basic reason for splitting msgid from msgstr is that the docs team writes the msgid's, the translation team supplies msgstr's; hence package i18n is a little different than traditional xgettext on *.c.
a) msgid's, not just msgstr's, need to be handled. msgid's are not necessarily constant,
If I update specspo, it may result in that descriptions of already installed packages change or disappear. Is it this sense of "not ... constant" you refer to?
Unlike, say, error messages with xgettext *.c, summary/description/group are much softer, so text divergence is acceptable.
Yes, that's a feature, at least for the docs team editors, because text can be updated in the field without having to wait for "make world" \of the next distro release.
It's also a feature for translation teams, which are no longer subject to the tyrrany of a distro release deadline, specspo could/should be released as needed (i.e. when msgid's change from docs team), not when there is a distro release.
Sure, specspo needs to be burned on the CD, there are alternative update pathways that could/should be used for specspo.
Again, these are process, not implementation, solutions so my feature may very well be your bug ;-)
I consider that a bug. One of the bugs I'm trying to solve here.
If I do "rpm -qip xmms-1.2.7-1.i386.rpm", with specspo installed, I get a description not mentioning MP3. If I uninstall specspo, or change to locale C or so, I get the package's original description, mentioning MP3.
Similarily, if I to "rpm -qi mpg321" on a system which still has this package, but current specspo, I don't get the description translatied. There was a translation, but it is not part of current specspo.
In both cases, the messages, and translations of them, which existed at the time of package generation is better than the current situation. They ought to come and go with the package itself.
Confusing? You betcha, many developers are suprised when they look for their edits to spec files to appear with "rpm -qi foo".
But that's a process (i.e. send patch to docs team, not edit spec file) rather than a packaging problem.
rpm can go several ways here.
If I go the way I want, then description/summary/group will be removed from packages entirely and problem will cease to exist.
Controversial? You betcha, as it appears that I'm trying to deny users access to descriptions of packages when in fact something else is intended.
nor is there (or at least gas there been)sufficient time late in a release cycle to manage "make world" rebuilds to include i18n, too many things can break.
That could of course be a problem.
To me it seems it would be possible to freeze descriptions of the new packages earlier. Like already by now in the current cycle. And also make them available for translation at this time. Then they could be there when the final build is done.
We've tried freeze, there's often too much package rearrangement during a release cycle for an early freeze to be effective.
Might work now, but there's still lots of package churn.
c) the goal must be to have i18n tags in metadata, fetching from the payload is a costly decompression.
I must have misunderstood something. In message 20030724114226.Q18401@devserv.devel.redhat.com you said:
IMHO: i18n does not belong in rpm metadata anymore than i18n belongs in tar/cpio headers. Keep i18n out of packages, please.
I understood that to mean that you did not want the translations in the metadata. So I tried to sketch things obeying that, putting them elsewhere.
Sorry, my bad. There are 2 issues here:
a) using already existing metadata tag values as retrieval keys for i18n from somewhere.
b) the somewhere should not be the package payload because that will slow down the installer while the payload is read, looking for description/summary/group. In fact, because of genhdlist, anaconda does most of it's work without payloads being available.
But maybe I misunderstood this comment. If so, I guess one could try to extend the current "%description -l ...". As I understand it, this does become package metadata; at least it winds up in the Packages database file.
As you pointed out, this lacks coding information. Also, putting all translations in the spec file is not very convenient. They need to be fetched externally at build time. But if this is an acceptable method, these problems probably could be solved.
And, yes, the old means of adding text to spec files still exists, will probably exist forever. Red Hat has not used this since 6.1, and is very unlikely to return to this mechanism. OTOH, it does mostly solve the 3rd party single package i18n problem, the only thing that breaks is when there are package name collisions, specspo is preferred to header content. I question whether identically named package is really 3rd party packaging, but making the header tag retrieval order configurable (i.e. prefer header over domains, or vice versa) is one approach if that too needs solving.
Sure your scheme makes sense, but is possibly different than what rpm has been doing since 6.2. There are consequences for having to support multiple schemes for the indefinite future, not the least of which is the complexity involved.
Point taken.
IMHO the apparent driving force for revisiting an already solved problem is the perceived need to accomodate 3rd party package group/summary/description.
Personally, I have yet to meet (or hear of) any single person who has even attempted the translation.
Are we talking about translations of descriptions at all? Or only through external po files?
I was referring to summary/description/group.
I always include Swedish versions when I build packages of my own. (After rhcontrib.bero.org died, I've mostly circulated them among friends. Some could probably still be found out there; rpmfind found a stickers package for example.)
I may be uncommon doing this. But then again, including translations in the SPEC file is not very convenient. And is "%description -l" documented anywhere except for the change log and the source code? There is a chance not everybody is aware of the possibility. :-)
Again, I'm not at all averse to improving the subtleties of i18n handling in packages as long as rpm package format doesn't have to change; afaict the existing specspo mechanism can be used to have per-package domains quite easily.
73 de Jeff
Jeff Johnson writes:
Unlike, say, error messages with xgettext *.c, summary/description/group are much softer, so text divergence is acceptable.
Yes, that's a feature, at least for the docs team editors, because text can be updated in the field without having to wait for "make world" \of the next distro release.
I'm not sure about your argumentation here. WHY are these particular messages "softer" than others, and divergence more acceptable for them. And WHY is it important to be able to update these particular messages in the field and not others.
It could very well be that we simply have different opinions; that your feature is my bug. But I feel I don't understand your reasoning. I don't understand your motivation for the statements above. So I'm not sure.
If a package needs to be updated, being because of a bug fix in the code, a changed description, or an corrected dependecy, the natural thing would be to issue an errata for that particular package, it seems to me.
I fail to see why descriptions and summaries are so very different from other documentation in the package.
But maybe I misunderstood this comment. If so, I guess one could try to extend the current "%description -l ...".
And, yes, the old means of adding text to spec files still exists, will probably exist forever. [...] OTOH, it does mostly solve the 3rd party single package i18n problem, the only thing that breaks is when there are package name collisions, specspo is preferred to header content.
Rather than name collisions I'm more concerned about the lack of coding information. And, AFAIK, the lack of tools to automatically pick up contributed translations.
On Fri, Aug 01, 2003 at 12:22:47AM +0200, Göran Uddeborg wrote:
Jeff Johnson writes:
Unlike, say, error messages with xgettext *.c, summary/description/group are much softer, so text divergence is acceptable.
Yes, that's a feature, at least for the docs team editors, because text can be updated in the field without having to wait for "make world" \of the next distro release.
I'm not sure about your argumentation here. WHY are these particular messages "softer" than others, and divergence more acceptable for them. And WHY is it important to be able to update these particular messages in the field and not others.
description/summary/group are "softer" in the sense that the usage context of the output text is not quite as stringent as, say, strerror(3).
There are many ways to convey the information accurately, I'm quite sure that you as a translator have taken some liberties in the interest of accurately conveying semantic content, the alternative is babelfish, ick.
OTOH, the information in description/summary/group *MUST* be translated accurately, and it's quite possible to obliterate meaning with overly complicated mechanism. Fuzzies come to mind, often accurate, sometimes hilarious. Specspo has (potentially) the same problem as fuzzies, and the solution comes from solid process i.e. acceptance criteria for translation is "No fuzzies".
The equivalent for specspo and package header contents is "Must match", the devil is in trying to make this happen becuase of rpm's design goal, binary rpm's must be built. Red Hat has tried 3 or 4 solutions, none were adequate, specspo has been the "best" so far.
Updating msgid's seperately is a requirement imposed by the docs team on the implementor, me. I have no control over the constraint, you will need to explore WHY with the docs team (although you can probably guess the answers just as well).
It could very well be that we simply have different opinions; that your feature is my bug. But I feel I don't understand your reasoning. I don't understand your motivation for the statements above. So I'm not sure.
If a package needs to be updated, being because of a bug fix in the code, a changed description, or an corrected dependecy, the natural thing would be to issue an errata for that particular package, it seems to me.
Sure, but I question whether adding, "Buffer overflow #5642 fixed in version 4-5." is really a satisfactory solution. I'd rather see the bugs tracked through other means than description.
I fail to see why descriptions and summaries are so very different from other documentation in the package.
description/summary are different because the values are located in the package header, not the package payload, and must be accessible to anaconda before the package is installed. In fact, the info must be accessible in an empty chroot, although anaconda is "cheating" these days.
Demanding that rpm be able to extract text from payload before install breaks every known current use of rpm, and adds intolerable overhead as well, fishing the text out of payload. Far, far easier to have solely in metatdata, but that also means that traditional solutions, like gettext(3) and dgettext(3) are not at all useful for description/summary/group.
But maybe I misunderstood this comment. If so, I guess one could try to extend the current "%description -l ...".
And, yes, the old means of adding text to spec files still exists, will probably exist forever. [...] OTOH, it does mostly solve the 3rd party single package i18n problem, the only thing that breaks is when there are package name collisions, specspo is preferred to header content.
Rather than name collisions I'm more concerned about the lack of coding information. And, AFAIK, the lack of tools to automatically pick up contributed translations.
All I meant is that, say, "name(Description)", if found in specspo, will be used before any header resident text. Quite easy to change lookup order.
Lack of tools is a problem, yes.
Lack of priority to write the tools is a problem for me as well.
73 de Jeff
On Fri, Jul 25, 2003 at 11:26:42PM +0200, Göran Uddeborg wrote:
When running things like "rpm -qi" or redhat-config-packages
- When a description, summary, or group is to be displayed, a translation is sought by a call to dgettext() whith a domain name derived from the package being inspected.
Would this make sense? Is it approximately along the lines you meant? (To the extent you had them thought out.)
Yes, I think so.
Would it be appropriate to put these package po files in some specific hierarchy, separate from /usr/share/locale? (And do a corresponding call to bindtextdomain() before calling dgettext().)
It seems to be just a namespace issue to me; either in /usr/share/locale with a prefixed name such as rpm- or in a separate directory both seem fine. Maybe a separate dir is cleaner.
Is the needed information always available? Like, does rpm know enough in time to find the po files when quering a package file, for example?
Don't know.
How would one handle building single packages, not being part of a distribution? Maybe by having an RPM directive specifying a directory in the build tree to search for further message catalogs? Then the translations for this package would be part of the source of the package, which I guess would make sense.
A fair question, and I'm not there's an answer. Seems like "if you rebuild, you lose the translations"
Havoc
On Fri, Jul 25, 2003 at 01:18:15AM +0200, Göran Uddeborg wrote:
Jeff Johnson writes:
IMHO, the work is best left to for-pay translators
I wouldn't mind that!
Beind paid? Put Arabic on a resume and send it in. Don't worry about the laguage skill set, all your other skills are perfect. ;-)
(and editors, hackers are not necessarily the best redactors)
Oh! Thought there would be a catch!
Seriously, there are often corrections to the msgid's found by translator's that need to be pushed uphill. Some of these changes are best handled by a C locale translator aka editor.
73 de Jeff
-
Enrico Scholz -
Göran Uddeborg -
Havoc Pennington -
Jeff Johnson -
Pedro Morais -
seth vidal -
Stephen Smoogen