commons-app
Languages order preference
Some screens show labels (and depictions) of Wikidata items. If the Wikidata item does not have a label, the app picks a label in any other language.
Often, the app shows a label in a language I can't read (Turkish in the screenshot below) even though the Wikidata item has a label in a language I can read (such as Spanish):
It would be great if the settings let me choose not just one language (such as French in the screenshot below), but several languages with an order, for instance French,Spanish,Italian,English.
The UI could look like the Android OS language setting, but any better UI is welcome:
The setting would modify the SPARQL queries sent by the app (don't worry if you don't know SPARQL, I can help with the SPARQL part).
https://github.com/commons-app/apps-android-commons/blob/c3cd30ce5c88ad3abfbd77b59e2460585a3ff720/app/src/main/resources/queries/query_for_item.rq#L20
@nicolas-raoul I am a student at the Australian National University working in a 4 person team. We work on open source projects like this one. We are all new to this repository and would love to contribute. This issue is one we want to work on, however its currently assigned. May we know if there has been any development?
Issue #5755 also seems approachable, but we would really appreciate being assigned to this issue.
@AlexD4110 Any progress on this? If yes, would you mind sharing your findings? :-)
@nicolas-raoul Have there been any updates? We are keen to start working on the issue right away.
At first feel free to implement for description language only, as rdfs:label seem to be more complex. The relevant SPARQL part should be automatically generated. For instance if the user's preferred languages are Arabic, German, French, then the following SPARQL should be generated:
# Get the description in the preferred language of the user, or any other language if no description is available in that language.
OPTIONAL {?item schema:description ?itemDescriptionPreferredLanguage1. FILTER (lang(?itemDescriptionPreferredLanguage1) = "ar")}
OPTIONAL {?item schema:description ?itemDescriptionPreferredLanguage2. FILTER (lang(?itemDescriptionPreferredLanguage2) = "de")}
OPTIONAL {?item schema:description ?itemDescriptionPreferredLanguage3. FILTER (lang(?itemDescriptionPreferredLanguage3) = "fr")}
OPTIONAL {?item schema:description ?itemDescriptionAnyLanguage}
BIND(COALESCE(?itemDescriptionPreferredLanguage1, ?itemDescriptionPreferredLanguage2, ?itemDescriptionPreferredLanguage3, ?itemDescriptionAnyLanguage, "?") as ?description)
Feel free to either build that full SPARQL code block within the Java/Kotlin code. Or to imagine a simple templating system and write iteration tags in the SPARQL then replace them within the Java/Kotlin code, for instance:
# Get the description in the preferred language of the user, or any other language if no description is available in that language.
{LANGUAGES}
OPTIONAL {?item schema:description ?itemDescriptionPreferredLanguage_{LANGUAGE}. FILTER (lang(?itemDescriptionPreferredLanguage_{LANGUAGE}) = "{LANGUAGE}")}
{/LANGUAGES}
OPTIONAL {?item schema:description ?itemDescriptionAnyLanguage}
BIND(COALESCE({LANGUAGES}?itemDescriptionPreferredLanguage_{LANGUAGE}, {/LANGUAGES} ?itemDescriptionAnyLanguage, "?") as ?description)
That makes sense. We are in the process of finding a way to persist the data to send the nearbyController. Currently you use Locales but I don't want to change existing systems, especially now that we are working with multiple language strings. Can I know if its only the query for item to worry about?
If so can't we simply persist the data some other way and import it to the nearby places controller? The is a very simple line of function calls that finally result in the query for item, I can very easily change inputs to take in this extra array of language strings.
Also, we are thinking it would be better to have a limit of extra ordered language preferences to account for, maybe around 5.
This is a preference, so please use the classic Android preferences mechanism. I would recommend serializing them into a String, for instance: "ja,zh,ko,fr,pt,es,it,ro"
Please allow users to enter any number of preferred languages, not sure 5. Thanks!
Got it. Thanks for the help, we will ask if we need any help with the SPARQL once we get to that stage.
Similarly, this works for the class label:
OPTIONAL {
?item p:P31/ps:P31 ?class.
OPTIONAL {?class rdfs:label ?classLabelPreferredLanguage1. FILTER (lang(?classLabelPreferredLanguage1) = "ar")}
OPTIONAL {?class rdfs:label ?classLabelPreferredLanguage2. FILTER (lang(?classLabelPreferredLanguage2) = "de")}
OPTIONAL {?class rdfs:label ?classLabelPreferredLanguage3. FILTER (lang(?classLabelPreferredLanguage3) = "fr")}
OPTIONAL {?class rdfs:label ?classLabelAnyLanguage}
BIND(COALESCE(?classLabelPreferredLanguage1, ?classLabelPreferredLanguage2, ?classLabelPreferredLanguage3, ?classLabelAnyLanguage, "?") as ?classLabel)
}
@nicolas-raoul An update from our team:
The UI is done, we are now finalising the solution. As recommended, we have changed the defaultKVstore to hold an extra serialised language code string as the secondary language placeholder. For other systems, we made sure that only the appUI language code was extracted to be used.
We only want to use the full serialised language code for the systems that this issue updates. Like the nearby controller etc. So we have now set up everything so that the relevant methods in okHttpJson now get sent the full serialised language codes. Now its simply a case of integrating the SPARQL queries with the updated methods in the okHttpJson class.
@nicolas-raoul
Sorry for the delay but we think (hopefully) we have a good working solution that fixes #5826. We are planning on requesting a PR later today, but I had a question. We have almost finished #5755, and there is some overlap between the two issues (particularly in settingsFragment). Should we submit two PRs or one that solves both?
Also is it absolutely required that we implement tests? We don't know how much more time we have available to work on these issues so we want to submit the PRs sooner rather than later.
Hi @Adeeth101 , I believe our contribution guidelines are that unit tests are required for new features and enhancements. As this issue is an enhancement, I'd strongly recommend implementing basic unit tests. Keeping our test coverage up has helped tremendously with stability.
Even if there is overlap, better keep pull requests separate. Thank you! :-)
@nicolas-raoul We updated the PR to match specifications, to be honest our university is now moving to exam period that will end in 2 weeks. I am still eager to close the issue though, so if you need anything from me just let me know.