It helps a lot if the purpose of this tag is explained even to non-programmer people (like packagers). I suggest changing this sentence:
It may be used by the AppStream distro metadata generator to determine the translation status of the respective software.
to something like this:
It may be used by the AppStream distro metadata generator to determine the translation status of the respective software (e.g. which languages the software is translated into and how complete the translations are).
Similarly to 1), I didn't understand the term "translation domain" and I didn't manage to find useful help online. In the end I realized it's the name of the *.mo file (for gettext) and then it's clear. It would be helpful it that could be explained better somehow (for all translation systems), but I don't know how.
@hughsie said appstream-glib now supports .pak and .xpi translation files. I'm not sure about your reference implementation, but is it something that should be incorporated in the spec as well?
It is unclear that <translations/> (an empty tag) is valid and what exactly it means. It can mean "this software is not translated" or it can mean "the translation status can't be determined by our tooling". (Now that appstream-glib made this tag mandatory in default validation pass, this is a question that will be asked by every packager of either proprietary software or software using unsupported translation systems). It would be good to clarify this, and ideally support both meanings in some way.
Thanks for consideration.
The text was updated successfully, but these errors were encountered:
After the discussion in hughsie/appstream-glib#302, I have a few suggestions how to improve
<translation/>description in AppStream spec:https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#sect-Metadata-GenericComponent
to something like this:
Similarly to 1), I didn't understand the term "translation domain" and I didn't manage to find useful help online. In the end I realized it's the name of the
*.mofile (for gettext) and then it's clear. It would be helpful it that could be explained better somehow (for all translation systems), but I don't know how.@hughsie said
appstream-glibnow supports.pakand.xpitranslation files. I'm not sure about your reference implementation, but is it something that should be incorporated in the spec as well?It is unclear that
<translations/>(an empty tag) is valid and what exactly it means. It can mean "this software is not translated" or it can mean "the translation status can't be determined by our tooling". (Now that appstream-glib made this tag mandatory in default validation pass, this is a question that will be asked by every packager of either proprietary software or software using unsupported translation systems). It would be good to clarify this, and ideally support both meanings in some way.Thanks for consideration.
The text was updated successfully, but these errors were encountered: