Skip to content
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

Support languages tag #37

Closed
iainlane opened this issue Feb 13, 2017 · 8 comments
Closed

Support languages tag #37

iainlane opened this issue Feb 13, 2017 · 8 comments

Comments

@iainlane
Copy link
Collaborator

I was looking at the kudo code in gnome-software, and the "translated into my languages" thing was reported as a problem in Ubuntu since it was never shown as enabled.

For that to work, we would need to support emitting the languages tag.

Has this been considered before? It would require looking into `.mo' files, which means extracting packages, which is a bit slow. Maybe therefore it should be a feature?

@ximion
Copy link
Owner

ximion commented Feb 14, 2017

Yes to all of your questions ;-)
This is actually already on my todo list, but I wanted you to finish libmo first, then we can use this to read the metadata from .mo files.
Another annoying thing will be finding .mo files reliably (I will probably reserve another db-key in the contents db for this, similarly to what we do with icons, and only ever read the .mo files when the software's metainfo tag has a "translation" tag)

@Beuc
Copy link

Beuc commented Jan 27, 2019

Hi!
Is this tool used for the Debian metadata?
I just hit this issue and it was quite hard to track down.

Here is some discussion about how this feature is implemented in appstream-builder (part of appstream-glib) and Fedora:
https://gitlab.gnome.org/GNOME/gnome-software/issues/583

@ximion
Copy link
Owner

ximion commented Jan 27, 2019

I accept PRs to make this work ;-)
Originally I was waiting for @iainlane 's https://github.com/iainlane/mo library to make implementing this feature much easier, today it just needs someone to do the work.
The localization tag is implemented only for fonts currently.

@Beuc
Copy link

Beuc commented Jan 27, 2019

I have no time to work on this, unfortunately.
AFAIK this already works in Fedora - isn't there a way to grab the working implementation?

@ximion
Copy link
Owner

ximion commented Jan 27, 2019

No, the two programs work very differently, so unfortunately it's not a case of "just copy it".
However, since I am already working on AppStream this weekend, I might be able to at least make a smaller implementation that works with Gettext (Qt translations also don't look that hard, so maybe I'll do these as well)..

@ximion ximion closed this as completed in dce23fd Jan 27, 2019
ximion added a commit that referenced this issue Jan 27, 2019
Since locale can be in pretty much any installed package, more advanced
logic is needed to find them.
The current implementation is only for Gettext, but adding Qt
translations will be much easier now.
The new implementation also *requires* the presence of a <translation/>
tag in order for this feature to work. This will likely not be changed,
explicitness just beats the complexity required for heuristics here.

CC: #37
@Beuc
Copy link

Beuc commented Jan 28, 2019

Great!
I have a meta-package with several gettext domains and a <translation> tag, can't wait to see how this plays out :)

@ximion
Copy link
Owner

ximion commented Jan 28, 2019

@Beuc You will have to have a <translation/> tag with your gettext domain in the metainfo file for this to work, see https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-translation
As far as I can see, that tag isn't currently present.

@Beuc
Copy link

Beuc commented Jan 28, 2019

Apparently the system didn't import yesterday's release yet.
Also I mistakenly linked above the old non-metapackage (freedink-engine), not the actual metapackage (freedink) which is not present yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants