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

Make it possible to fall back to other languages #293

Closed
aleixpol opened this issue Dec 1, 2020 · 3 comments
Closed

Make it possible to fall back to other languages #293

aleixpol opened this issue Dec 1, 2020 · 3 comments

Comments

@aleixpol
Copy link
Collaborator

aleixpol commented Dec 1, 2020

Much like we do in UIs, we need to be able to get a different text if the application we're browsing isn't available on our configured language:
https://bugs.kde.org/show_bug.cgi?id=420891

Otherwise we are not very useful on other (minoritary?) languages.

@ximion
Copy link
Owner

ximion commented Dec 1, 2020

We already do that fallback, however, if a translator has translated any part of the description text, we show what we got and deliberately don't produce a half-English half-translated mix of a text.
In the linked case, unfortunately, a translator translated a tiny part of the description, yielding this result. I wonder whether we should add a rule like "first paragraph has to be translated", and if it isn't, completely fall back to the English text.

@ximion
Copy link
Owner

ximion commented Jan 24, 2021

This "first paragraph needs translation" is actually not possible to implement - AppStream has no idea what the "first paragraph" is when iterating through all p/li elements, and it will just show all of them into the respective locale buckets. There is no programmatic way to test whether a paragraph was translated.

I could of course implement some rule that "more than one paragraph needs to be translated", but some translations only have one paragraph. Also, potentially that paragraph is long enough so that it is actually a meaningful translation and should actually show up instead of being thrown out.

So, at the moment I see no way to fix this, as AppStream doesn't (and can't) understand whether the text it displays has meaning, and any "you must have X amount of translated text" rule will certainly produce regressions. Better heuristics would depend on translations being in the right order, which is also nothing we can assume is the case, and doing so may break other usecases.

So, I think this is really a matter for the toolchain that has all the information that AppStream doesn't have once the final XML data is generated: The KDE translation tools. Those could simply prevent translating the XML if a certain language localizes less than 40% of the application's metadata, thereby causing English text to be shown to the user.

ximion added a commit that referenced this issue Feb 2, 2021
This is a workaround that resolves issues like #293
Ideally upstreams should ensure their translation texts are sane, but
with these heuristics we will at least display some sensible thing if
only one paragraph is translated.
(Translators now need to translate at the very least either more than 3
elements of the description or all of the elements if there are less
than 3 to translate)
@ximion
Copy link
Owner

ximion commented Feb 2, 2021

I've implemented a workaround for this which should definitely address some of the more extreme cases. For the fine tuning, upstream projects will really have to do the work though to ensure their translations are sane.

@ximion ximion closed this as completed Feb 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants