On 6 November 2013 03:49, T.C. Hollingsworth <tchollingswo...@gmail.com> wrote: > Unfortunately, the schema says the latter is invalid. Is the schema > wrong or intltool wrong?
This is what we do in GNOME: https://git.gnome.org/browse/gnome-software/tree/data/appdata/org.gnome.Software.appdata.xml.in gets translated by intltool into http://people.freedesktop.org/~hughsient/temp/org.gnome.Software.appdata.xml -- so we have a document structure like: <description> <p> Software allows you to find and install new applications and system extensions and remove existing installed applications. </p> <p xml:lang="cs"> Aplikace Software umožňuje vyhledávat a instalovat aplikace a systémová rozšíření a odebírat stávající nainstalované aplikace. </p> </description> > If we have to do it by paragraph, having scripty merge the > translations back into the original XML is going to be ugly... The reasons I chose to do it this way were mainly because most translators hate translating XML tags. And if one translator does something slightly wrong, the whole document becomes invalid. For instance, asking the translators to translate this source string: <p>This is the list of features:</p><ul><li>Massive color database</li></ul> If they translate this as: <p>This is the list of features:</p><ul><<li>Massive colour database</li></ul> This fails hard when the document is installed (as in, fails to parse, and so doesn't get used). Most translators won't validate the resulting XML document before translating. In GNOME we'd ask them to translate "This is the list of features:" and "Massive color database" which is much more sane and basically impossible to get wrong. If you have a translation tool that is able to somehow rebuild the tag structure and only ask the translators to actually translate the prose then I suppose supporting something like <description xml:lang="cs"> in AppData makes sense, but only if it takes more than one translator replacing <p> with «p» to screw things up. > Could we just ship the .mo files in /usr/share/app-info/locale or so > and just have the extractors copy those files unconditionally (e.g. > regardless of the existence of a .desktop file) when trawling through > packages? 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. 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. Richard.