Page MenuHomePhabricator

meta=siteinfo&prop=langlinks should indicate whether a language is RTL
Closed, DuplicatePublic

Description

https://en.m.wikipedia.org/w/api.php?action=query&format=jsonfm&meta=siteinfo&siprop=general%7Clanguages&prop=langlinks&llurl=true&lllimit=max&titles=Tofu

This returns language names and article titles in many languages (which is used to construct a language switcher interface on the mobile web interface). To do that properly, mobile we need to identify which languages are RTL and which are not.

Expected: Return an rtl property when a language is RTL.

Note: MobileFrontend is forced to workaround the lack of this directionality and ships a list of language codes that are considered RTL incurring technical debt. Blocked on T190129

Details

Reference
bz72153

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:43 AM
bzimport added projects: MediaWiki-API, I18n.
bzimport set Reference to bz72153.
bzimport added a subscriber: Unknown Object (MLST).

At a glance, it seems this would require fetching a Language object for every single language. That may be prohibitive from a performance perspective.

Pulling in some i18n experts.

Even if we can skip that part (as with Language::getFallbacksFor()), it would still require loading language info for every language which has the same concerns.

I said on IRC that many people use jquery.uls.data for getting the direction of a language. I do not know if that is possible for you.

I don't understand the bug summary.
https://he.wikipedia.org/w/api.php?action=query&meta=siteinfo&siprop=general
lang="he" rtl=""
WORKSFORME

He is asking for rtl="" for all supported languages, not for the content language (where the flag exists).

https://he.wikipedia.org/w/api.php?action=query&meta=siteinfo&siprop=languages

For what the dir is needed in this context?

Another solutation maybe where to add the dir (rtl or ltr) to each language link from the prop=langlinks, than there is no need to fetch all languages and just use the one which are needed.

By the way:
For performance you can actually change meta=siteinfo&siprop=languages by llprop=autonym

The goal is to render a list of all available languages and align them right to left or left to right depending on the language script.

Aklapper triaged this task as Low priority.Mar 23 2015, 8:56 PM
Amire80 moved this task from Backlog to MediaWiki-core on the RTL board.Jul 16 2015, 6:29 PM

This proposal is selected for the Developer-Wishlist voting round and will be added to a MediaWiki page very soon. To the subscribers, or proposer of this task: please help modify the task description: add a brief summary (10-12 lines) of the problem that this proposal raises, topics discussed in the comments, and a proposed solution (if there is any yet). Remember to add a header with a title "Description," to your content. Please do so before February 5th, 12:00 pm UTC.

Tgr updated the task description. (Show Details)Feb 5 2017, 7:54 AM
Krinkle renamed this task from meta=siteinfo should allow client to identify RTL languages to meta=siteinfo&prop=langlinks should indicate whether a language is RTL.Feb 6 2017, 7:36 PM
Krinkle removed a subscriber: wikibugs-l-list.
Krinkle added a subscriber: Krinkle.Feb 6 2017, 7:41 PM

Note that meta=siteinfo already exposes a siteinfo.rtl property on sites that have an RTL content language. I've updated the summary to specify that this task is specifically about the langlist, not the main siteinfo itself.

As for the actual task, I'm not entirely sure that this is the most adequate solution to the problem at hand. It is not the responsibility of this data module to know whether a language is RTL or not. If we add this we could be opening the way to add lots of unrelated information to API modules that consumers may need at the same time.

However from what I can tell, distinguishing an RTL language is a much more common need in general. A simple isRTL() method on mw.language (client-side) and Language.php (server-side) might solve this need in a more maintainable way that also more re-usable and performant.

In the Intuition tool I solved this by providing a cached index of known RTL language-codes (which is a fairly short list), and the checks do a cheap in_array/indexOf lookup.

Anomie added a comment.Feb 6 2017, 9:45 PM

@Krinkle changed the title from "meta=siteinfo should allow client to identify RTL languages" to "meta=siteinfo&prop=langlinks should indicate whether a language is RTL".

This title makes little sense. meta=siteinfo and prop=langlinks are two completely separate modules. I believe the intention of the original request was that meta=siteinfo&siprop=languages should indicate directionality, which would then be cross-referenced with the language of each link output by prop=langlinks.

Jdlrobson raised the priority of this task from Low to Normal.Feb 27 2018, 5:46 PM

I'm going to take a look at this problem and see what fixing on the API would look like and what a mw.language.isRTL method looks like. I'll probably pull @pmiazga

Change 415176 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/core@master] Expose language direction in langlinks queries

https://gerrit.wikimedia.org/r/415176

Change 415187 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/core@master] RTL lookup is a static method

https://gerrit.wikimedia.org/r/415187

Amire80 moved this task from Untriaged to RTL on the I18n board.Feb 28 2018, 12:29 PM
Jdlrobson moved this task from Inbox to Next up on the User-Jdlrobson board.Mar 6 2018, 5:56 PM
Jdlrobson moved this task from Next up to Blocked on the User-Jdlrobson board.Mar 26 2018, 5:45 PM
Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)

Change 415176 abandoned by Jdlrobson:
Expose language direction in langlinks queries

https://gerrit.wikimedia.org/r/415176

Change 415187 abandoned by Jdlrobson:
Generate RTL languages via maintenance script

https://gerrit.wikimedia.org/r/415187

Change 510705 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/core@master] Add action=query&meta=languageinfo API module

https://gerrit.wikimedia.org/r/510705

Change 510705 merged by jenkins-bot:
[mediawiki/core@master] Add action=query&meta=languageinfo API module

https://gerrit.wikimedia.org/r/510705

Restricted Application removed a subscriber: Liuxinyu970226. · View Herald TranscriptJun 5 2019, 1:52 PM

Thanks indeed @Lucas_Werkmeister_WMDE !

I have a question. Does this API work within langlinks module? If not, how difficult would you estimate it to be to add that?
https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&format=json&formatversion=2&origin=*&meta=siteinfo&siprop=general&prop=langlinks&lllimit=max&titles=Qatar&llprop=url%7Cautonym%7Clangname&llinlanguagecode=en&origin=*

I can't see a way to add langdir as a prop to llprop however can get the dirs if I do:
https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&format=json&origin=*&prop=langlinks&meta=siteinfo%7Clanguageinfo&titles=Qatar&formatversion=2&llprop=url%7Cautonym%7Clangname&llinlanguagecode=en&lllimit=max&siprop=general&liprop=code%7Cdir&licode=*

The problem with this is the payload seems significantly large and I'd like to minimise it (since that can slow down the mobile display of languages).

I don’t think there’s currently a way to do that in one compact request – you can either get the directions of all languages, as in your second link, or you can first make the langlinks request, gather the language codes from that, and then ask meta=languageinfo for the directions of only those language codes.

One way to fix that would be a kind of “language generator”, analogous to normal generators, that could be provided by langlinks (and also wikibasecontentlanguages)… but that would require a lot more work, I think, and might be overkill.

but that would require a lot more work, I think, and might be overkill.

+1, that seems like overkill to me too.

If you want to reduce response sizes, you might look into having your app cache the results of siteinfo and languageinfo rather than requesting them every time.

Thanks for information.

Caching doesn't make too much sense as the language overlay is only loaded once. We could cache in localStorage but I'm not sure that's worth the saving.

I will take a look at the payload for the current query plus rtl information and see if it saves anything on the frontend (right now we just maintain a javascript object with this information... and could probably generate that from the api request in a build step if we wanted.