-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Translation support as a metainfo quality requirement #337
Comments
IMO translation tooling is not good enough for this (or docs are that bad, that I just couldn't figure it out) - anyway it's not easy enough. I'm unsure if weblate speaks the correct formats. https://docs.weblate.org/en/latest/formats.html They hint at https://github.com/translate/translate to enable weblate to parse from/to, but likely that also needs work on their end. Then again, I'm not 100% if this is the correct approach. I'm stuck, as flathub uses weblate, I can't create a new project as my one free project is already used. So I can't explore this. I created xbmc/xbmc#25298 to try to test this on kodis weblate instance (they got their own), but haven't spend more time on it. Cmake help would be great or somebody figuring out everything as an example somewhere else and documenting everything. |
Weblate supports the gettext PO format, which can be used with XML files. But FWIW, handling translations with Weblate or similar services isn't strictly necessary; it can be done manually as well. Even that is a lot better than having no handling of it at all. If Weblate is set up to handle PO translations, it commits to the Apps that use something other than gettext can just roll with their solution as long as it works for the metainfo. This is still highly technical, though, so I'm getting increasingly unsure if it's worth mandating. |
This should not be enabled unless we have a large and diverse pool of apps passing the guidelines and the tooling/docs situation improves. Automating the checking part is easiest, you can just check for the The rest is complicated, as there is no clear documentation on appstream's side and the tooling is a bit lacking. Poeple often use their own python scripts using itstool to manage this. KDE has their own tooling for official apps for this. Only meson allows to have translations in a nice way, for other buildsystems, without clear tooling, the metainfo file needs to be kept merged with the translated data. |
Agreed! From skimming through the store with Spanish enabled (which I assume is the largest non-English language in terms of translations), it seems like at least most apps built for GNOME and KDE do pass. I didn’t pay much attention to non-GNOME/KDE apps, but I assume there are a couple of those with metainfo translation support already. The docs and tooling situation isn’t nearly as good at the moment, however. So that’s a pretty significant roadblock. |
Now that Flathub supports showing translated metainfo for apps, I wonder if it would make sense to require basic metainfo translation support for being featured. For people who do not use English widely in their day-to-day lives, app metainfo being translated can make a huge impact on its perceived quality. Translation infrastructure is also mostly a technical endeavour, and requiring developers to at least make it possible to submit translations to the app metadata with .po files or a service like Weblate, doesn't seem unreasonable to me. The amount/coverage of translations shouldn't have anything to say as long as it's possible to contribute to them.
This is definitely not worth it if it requires a manual inspection for each app, though. Here are some ways we might be able to control it automatically:
metainfo.xml
andappdata.xml
in thepo/POTFILES
list in the app's source code repository (only works for apps that use gettext)translation
AppStream tag somehowThe text was updated successfully, but these errors were encountered: