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
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Invalid | Amire80 | T30708 BiDi: LTR and RTL mixed up (tracking) | |||
| Resolved | • Nirzar | T66617 List of languages looks strange when mixes RTL and LTR languages | |||
| Duplicate | None | T74153 meta=siteinfo&prop=langlinks should indicate whether a language is RTL |
At a glance, it seems this would require fetching a Language object for every single language. That may be prohibitive from a performance perspective.
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.
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.
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.
@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.
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
Change 415187 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/core@master] RTL lookup is a static method
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
Change 510705 merged by jenkins-bot:
[mediawiki/core@master] Add action=query&meta=languageinfo API module
Thanks for shepherding this @Lucas_Werkmeister_WMDE and thanks to everyone else who worked on this and helped in review.
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.
+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.