On Wed, Nov 6, 2013 at 1:40 AM, Richard Hughes <hughsi...@gmail.com> wrote: > I'm not sure how well this will work, at least in gnome-software we > allow the user to match on a keyword cache using the "C" name, and > also the UTF8 and normalized versions of their current locale.
Nah, I meant for the extractor tools to read in the translations into the big giant AppStream XML; no magic needed in the software centers, nor would there be any need for users to have to have the package that has these .mo files installed, which kind of defeats the purpose. > I also > don't think the extractor tools (from desktop+appdata->AppStream > metadata) are going to be able to switch locale like that, and reading > the gmo files manually isn't something I'd look forward to > implementing. The gettext module built in to Python can read in translations from arbitrary domains in arbitrary languages sourcing locale files from arbitrary directories no sweat, so this would be a fairly simple patch to fedora-appstream. (I'm happy to resubmit this suggestion in patch form too, BTW; just wanted to make sure it was something you were interested in implementing, first. ;-) I was originally going to suggest we do something like this but with seperate <application xml:lang="foo"> XML fragments instead of po files, just to make things simpler in the appstream extractor, but after looking at what it took to get such XML output from KDE po files I discovered that the gettext goop to implement this in fedora-appstream itself isn't really any more complicated than the etree goop to suck it out of those XML fragments instead. Doing it this way also has the side effect of ensuring that translators never need to deal with XML, ever. In general I think being able to ship translations separately would be a big improvement to the i18n story for all the software centers that implement this spec. It has more benefits than just aiding KDE in implementing it. For instance, in Fedora we're probably going to be stuck with having AppData included as SourceN files in SRPMs for quite some time. At the moment, translation of those is pretty much impossible. Hooking a bunch of random SRPMs up to Transifex would suck, as would trying to merge back translations into the XML files in Fedora dist-git in some automated fashion. But with something like this it would be fairly easy to extract all the appdata.xml files shipped as additional sources in SRPMs, dump it in Fedora's transifex instance, and get them back out and working in GNOME Software and Apper with minimal difficulty. Also, I suspect that you don't want GNOME Software in other languages to be a hairball of that language and English forever, so you're probably going to want to turn off display of apps that aren't translated at some point. You could say that "hey, obviously upstream doesn't support that language very well, so including it in the app center in that locale is pretty useless", which would be true to some extent, but that ignores multilingual users who prefer to use their computer in their native language but are happy to use an app in English if it's awesome enough. (There are a lot of English-only dev tools, for instance. I'd hate to lose would-be free software contributors just because they prefer their desktop to be in their native tongue.) Adding a "show me a mishmash of Esperanto and English plz" checkbox is really a terrible option, so if we want to have complete coverage of translated application data in the future—and I think we really do—we're going to have to have infrastructure for distro translators to pick up the slack, and this would be a big head start. -T.C.