Talk:Universal Language Selector

Jump to: navigation, search

About this board

Edit description
By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL

Arabic Standard: ج and د are missing

2
Summary by Nikerabbit

Documentation updated.

2A01:CB08:760:F200:1486:D8:147E:9F71 (talkcontribs)

In Arabic Standard, two important letters are missing: ج and د . Please could somebody make them available?

Amire80 (talkcontribs)

Hi,

Thanks for the comment! The letters are there, but they were missing from the table. I added them now.

Please make the screenshots translatable

1
Guycn2 (talkcontribs)

I want the screenshots for the Hebrew version of this page to show a Hebrew interface rather than an English interface.

Could you make the images' names translatable?

Reply to "Please make the screenshots translatable"
Olaf Studt (talkcontribs)

Since the German Wikipedia only recently supplies web fonts, I added missing {{lang}} templates to a lot of articles during the last days, and I encountered several problems:

The thing I saw last is perhaps the easiest to fix: The mechanism is case sensitive. {{Lang|km|}} works, {{Lang|Km|}} doesn't.

Script suffixes as {{lang|bo-Tibt|}} or {{lang|am-Ethi}} do not work, so I had to change {{lang|bo-Tibt|}} to {{lang|bo|}}.

For the Ge'ez script, only {{lang|am}} and {{lang|ti}} work, {{lang|gez}} (Ge'ez language) and {{lang|tig}} (Tigre language) don't, so I left de:Ge’ez (Sprache) and de:Tigre (Sprache) without {{lang}}. Nor do all the smaller Ethiopian Semitic languages (for these, maybe the suffix -Ethi should be mandatory because some of them are also written in Arabic or hardly written at all).

For the Tibetan alphabet, only {{lang|bo|}} and {{lang|dz|}} work, not the other Category:Languages written in Tibetan script.

Nemo bis (talkcontribs)

As for case sensitiveness, you should just make the template convert to lowercase with the {{lc:}} magic word.

Mps (talkcontribs)

Converting the annotations as a whole to lowercase is going against the recommendations of RFC4646 and the therein mentioned ISO standards w.r.t. to the format of each annotation part. It is the responsibility of the implementations (here the Universal Language Selector) making use of the annotations to treat them internally as case-insensitive. Additionally, your proposal would only address this singular issue with this very template, but neither other templates using language annotation nor where language annotation is done without templates, and thus not solve the general issue.

Nemo bis (talkcontribs)

What general issue? I'm not aware of a general issue. People seem to be mostly using language codes correctly.

The RFC says:

  The format of the tags and subtags in the registry is RECOMMENDED.
  In this format, all non-initial two-letter subtags are uppercase, all
  non-initial four-letter subtags are titlecase, and all other subtags
  are lowercase.

Hence {{Lang|Km|}} is incorrect, I don't see why the template shouldn't fix it. Sure, the RFC also states "All comparisons MUST be performed in a case-insensitive manner" (which could be an issue for the extension or for core), I was merely giving a practical suggestion about that specific case.

Mps (talkcontribs)

The general issue is that the Universal Language Selector is not performing its comparisons in a case-insensitive manner, otherwise {{Lang|km|}} and {{Lang|Km|}} wouldn't behave differently.

Besides, if every input would just be filtered through an "{{lc:}}" something like "{{lang|bo-Tibt|}}" would just become "{{lang|bo-tibt|}}". And as you say "People seem to be mostly using language codes correctly", so just lower-casing everything would result in mostly non-recommended outputs, just for the sake of removing rare non-recommended (but nevertheless allowed) cases like "{{Lang|Km|}}". Of course one could to some parameter parsing (where I doubt the performance disadvantages are compensating the advantage of a not required wellformed output for a few malformed inputs), but this does not change the situation that a "{{lc:}}" would only treat the symptoms but not the cause.

Nemo bis (talkcontribs)

Again, I never said "lowercase everything". Your point is very clear and I'm unable to comment it, no purpose in repeating.

Santhosh.thottingal (talkcontribs)

Issue about languages written in Tibetan script is reported and tracked here https://github.com/wikimedia/jquery.webfonts/issues/29. It also tracks gez and itg. Thanks

Reply to "Several problems with web fonts"
Patrick87 (talkcontribs)

Hi all,

is there a way to disable ULS as a user setting? I never use it and since it's JavaScript is distracting me on page load since it's displayed with a noticeable delay.

Regards

Siebrand (talkcontribs)

Yes. See Universal_Language_Selector/FAQ#How_can_I_disable_Universal_Language_Selector.

Patrick87 (talkcontribs)

Thanks, but this only allows to disable "input methods", not ULS completely. I hope there is more I can do?

Patrick87 (talkcontribs)

Thank you for you replies so far. Sadly this wasn't the answer I had hoped for.

Anyway I discovered two Bugzilla bugs regarding the issue:

  • bugzilla:46306 is about adding an option to user preferences to diable ULS completely
  • bugzilla:46744 is about finding better default settings or automatically detecting useful settings for ULS so it's not shown for people that probably don't need it.

@Nemo: Can you elaborate on why ULS can't be completely disabled on a user basis in your opinion? You said something about API functions used by other extensions in bug 46306? Anyway the user front end with all it's options is probably independent from the core of the extension anyway, so I don't see a problem here, even if your statement is true.

Drajay1976 (talkcontribs)

I was directed here from Bugzilla:46306 by Erik Moeller. I dont have much technical knowledge and I dont know why a user cannot be given the option to diable ULS completely. If the users request that they should be given an option to swith ULS off completely, that must be provided unless there is some sound technical reasons which makes it impossible. Is there any such reason?

Patrick87 (talkcontribs)

There was given no reason at all so far (at least none of which I would be aware of and I searched a lot, on Bugzilla as well as on Wiki pages).

I even wrote an e-mail to Siebrand who is the project manager responsible for ULS (and who closed the bug as "WONTFIX") and asked him for a statement on why this wasn't considered. However he didn't respond to my mail sent on Monday yet (neither directly nor by a comment in Bugzilla nor on a Wiki page)

This is highly disappointing in my opinion! There is notable request by the community for such a feature. The WMF declines to fix it however and (which is worst) doesn't even care do give a reason for it.

  • If there are good technical reasons, that make such an option hard to implement, that would be acceptable (although unsatisfactory).
  • If this is another move - like in the VisualEditor case - to force established editors to have a look at it to find bugs, that would at least be a comprehensible motive (although questionable action).

Any way I highly suggest somebody at WMF to elaborate on the issue, otherwise this discussion will go on forever with us not knowing anything and you being bugged by us because of this!

Eloquence (talkcontribs)

I see disabling ULS entirely as akin to disabling the preferences section. ULS simply surfaces options and features related to languages in a location of the user interface where they are likely to be sought. From what I've seen in the ml.wp and ta.wp discussions, the desire to disable seems to mostly stem from identifying ULS with overriding the default font. That is, however, not inherently something that ULS does -- the default font can be configured on a per-language level, and completely disabled (both by communities in Common.js and in the ULS config itself) if needed.

What other reasons or motivations are there to completely disable it? If ULS loads more JavaScript than strictly needed, for example, that seems like an area of optimization but surely solvable in its own right. Is it causing any problems or interference?

Patrick87 (talkcontribs)

I gave several reasons in many places already, but I'll elaborate on it again in the hope that you will consider those issues.

First of all I think many users don't need ULS at all:

  • The "default" user which is writing in a Latin language on a Wikipedia that is using a Latin language has absolutely no need for input methods or different fonts, therefore two unnecessary features added, nothing gained.
  • The third main feature of ULS, changing interface language, is redundant to the setting in user preferences. It is a great feature for not logged in-users, I don't want to deny that, but its totally useless for logged-in users. Setting the interface language is normally a one time Job one does on account creation or shortly after. Afterwards the setting is not needed anymore (and surely not directly in ones face on every page). And this setting is normally sought in a central place the user's preferences, where all settings should be made. What makes this single setting so much more important than others, that it needs to be presented separately in the UI? I often change my skin to check compatibility maybe add a button for that one, too?

Besides those nobody was able to tell me if ULS offers any further features, that may not be directly visible. But if there are no such "hidden" features ULS is totally useless for me (and probably many others) and only clutters the UI.

Now to the problems this is actually producing besides being redundant or even useless:

  • ULS is loaded by JavaScript. That means it's slow as hell by default (whatever you are going to do to optimize it). And it adds overhead to every page load.
  • Since it's loaded by JavaScript the buttons are added to the UI with some delay. This causes "flickering" which looks totally unprofessional and is distracting the eye.
  • Currently it even renders some pages with many language links useless (the loading of the script takes ages, blocking everything). There are bug reports already and I'm sure it will be fixed eventually, but it is a good example why I would have preferred to be able to disable ULS in the first place. It would have saved my needless hassle with a feature I never used and will never use.
Nemo bis (talkcontribs)

On choosing the default font and consensus (bugzilla:46306#c43), I'm a bit concerned because it enables a paradox: if a font is supported very bad by normal systems, wikis will have users coming only from uncommon systems/setups, hence consensus will be skewed; the more a webfont is needed, the more likely it is to be disabled based on consensus...

Of course, as Churchill would say, it's the worst except that the alternatives available so far would be worse.

Siebrand (talkcontribs)

I fully agree with your concern. I do not agree with you that the Churchill invocation is applicable.

Patrick87 (talkcontribs)

After more than a month there is still no satisfactory answer why an option to disable ULS is not considered at all.

Meanwhile

  • ULS keeps jumping in my face with needless messages (e.g. "Language changed from Deutsch") when I come to Commons (where I set my UI language to English) from a file description page on German Wikipedia (where I have set my UI language to German).
  • Produces needless flicker on page load due to the delayed loading of webfonts of languages I don't speak or even can read anyway.
  • Slows down the already slow page load of JavaScript-overloaded Wikipedia pages even more (I did some performance measurements and often around one third of the used time "could be ULS" according to devs. But hey, who cares, its "only" one third why should anybody care to optimize ULS further or at least offer an option to turn it off, if it does not lock the browser for most of Wikipedia users?).

I'm deeply disappointed by you guys! This is not how great software is designed. It's ragged, ignorant and unfinished. If you don't have the manpower to develop such extensions to the end then delay deployment or please offer an off-switch for those who are not dependent on the offered functionality!

Reply to "Disabling ULS"

Nastaliq font for Urdu

12
Summary by Nemo bis

We'd like to add a Nastaʿlīq (also written Nastalique, Nastaleeq, Nastaliq) font, but so far no free one was found. There is one which is worth asking about to the author.

Syed Wamiq Ahmed Hashmi (talkcontribs)

I would like to request the default font for Urdu to be a Nastaliq font like Jameel Noori Nastaleeq, Urdu Typesetting, etc. This proposal has been twice rejected here so I am raising the issue on the ULS. Further details can be had there. Hope no one objects...

Nemo bis (talkcontribs)

What font do you suggest? We did some research and Nafees Web Naskh was the only recent free font available, see bugzilla:46693. The others were either obsoleted or unfree.

Syed Wamiq Ahmed Hashmi (talkcontribs)

I was asking for a Nastaliq font, of which the best I've found is "Jameel Noori Nastaliq". Naskh (Nafees) is not the standard way of transcribing Urdu.

Nemo bis (talkcontribs)

That is, http://www.urdujahan.com/font.html ? Thanks for letting us know. The website and zip don't contain any information about licensing; another website says "License: freeware". If you wish this font to be included, please contact the author and ask a free license to be included. Also see Extension:UniversalLanguageSelector for more instructions.

TheDJ (talkcontribs)

This all requires some further clarification:

  • At a unicode level, this all uses arabic text (as far as I'm able to tell, and I'm not sure if there are differences in shaping)
  • Nastaliq is the traditional writing style of Urdu language.
  • Due to the availability of Naskh scripts (which are also easier to render due to more consistent line height), it has become more common for urdu to be represented in naskh in digital media.
  • This is considered to be undesirable however.
  • There is no known free nastaliq font.
  • There are however nastaliq fonts available on Windows 8, but since they share the same script, they apparently don't really get easily selected by the font systems.
  • There is a desire to make https://en.wikipedia.org/wiki/Template:Script/Nastaliq unneeded, but this is a requirement that ULS cannot fulfill because of the above reasons

So some points to address:

  1. A free Nastaliq font is desirable and
  2. En.wp doesn't really know what the Urdu wikipedia community thinks of this, it might be useful to figure that out.
  3. A temporary solution might be to make it possible to redefine system font styles in a certain language. So you could have in the font drop down for urdu:
    1. nastaliq system
      font-family: "Jameel Noori Nastaleeq", "Urdu Typesetting", sans-serif;
      
    2. NafeesWeb
    3. system default

There is a nice article on Nastaliq typesetting here

TheDJ (talkcontribs)

BTW, if Fraktur is an ISO15924 defined script variant, it makes you wonder why the different arabic script styles are not/should not defined. There was a very long discussion about this on the unicode mailing list that I have not yet entirely read: http://www.unicode.org/mail-arch/unicode-ml/y2005-m11/0094.html

TheDJ (talkcontribs)

There is this old non-unicode Nastaliq SIL font: http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=Nastaliq Not usable of course, but perhaps SIL. Open font library has Hussaini Nastaleeq though, which is MIT (X11) licensed apparently and a descendant of Nafees Nastaleeq. Might be interesting ?

Nemo bis (talkcontribs)

As you can see in bugzilla:46693, we were aware of the former, but not of the latter. It says however that it's a fork from CRULP's Nafees which, in the version linked from the bug, was not free; the page it links is down but Internet Archive has a copy, the license is not standard. It should be clarified whether the author got from CRULP permission to license his derivative under MIT license, or what.

TheDJ (talkcontribs)

@Nemo_bis Doesn't NafeesWeb have the exact same license though ? http://www.cle.org.pk/software/localization/Fonts/nafeesWebNaskh.html

Nemo bis (talkcontribs)

For that one Kartik found a waiver. Have you read the bug that I've linked about half a dozen times by now in this thread? :)

TheDJ (talkcontribs)

Well that information isn't in the ticket that I read. It is however hidden in the commit message.

This comment was hidden by C933103 (history)
Reply to "Nastaliq font for Urdu"
Verdy p (talkcontribs)

The Autonym font is not designed to display arbitrary text in all scripts.

For example it won't display arbitrary text in Chinese, or does not have correct coverage for displaying IPA transcriptions, and not even toponyms like country names (unless a few of them are needed later in the ULS if it has to include a regional selector for locales, instead of just a language selector: my opinion is that you'll select first the language using the Autonym font, but selection of regions will be fully translated with the rest of the interface, using a better font designed for that language with a more complete coverage of its native script).

The Autonym font also does not need coverage of most symbols, punctuations and digits (unless those characters needed for displaying some language names, including with disambiguation in parentheses).

However it should work to display at least all the language names listed in the ULS (or now proposed to be used in all wikis in language navigation bars, example at the bottom of Meta-Wiki main page). This means that its developement shoud monitor the evolution of the list of languages supported by Wikimedia (this font is not required to display all the many possible native language names in their script, until they get some some support in a Wikimedia site). This means that this font is only meant for usage in Wikimedia sites, or in sites that don't need more language names than Wikimedia.

Problems:

  • the font does not work when rendering some languages (supported by Wikimedia sites) in their native scripts (severe issue, we only see square boxes).
    Demos (using <bdi class="autonym" lang="my">{{#language:my}}</bdi>):
    • Church Slavic (cu)
      словѣньскъ / ⰔⰎⰑⰂⰡⰐⰠⰔⰍⰟ
    • Sichuan Yi (ii)
      ꆇꉙ
    • Burmese (my)
      မြန်မာဘာသာ (may render however in some wiki sites that provide some font fallbacks)
  • the font is poorly hinted for Georgian and some Indic language names in their native scripts, which are difficult to read:
    • Georgian (ka)
      ქართული
    • Sinhala (si)
      සිංහල
Santhosh.thottingal (talkcontribs)

Some of them are already addressed in upstream and will be available in wikis in a week time. See https://github.com/santhoshtr/AutonymFont/issues for a list of known issues. We also get requests from third party users interested in this font to add more languages. That also being addressed(slowly).

The recent changes can be seen at https://github.com/santhoshtr/AutonymFont/commits/master

Considering the number of scripts to be supported, it takes some time to get all languages in it, but definitely we are working on it. Your comments are appreciated.

Mzajac (talkcontribs)

There seems to be a basic lack of testing. Maybe just check that stuff works at all before releasing it on the public. Details at Talk:UniversalLanguageSelector/AutonymFont#Testing flaws.

Mzajac (talkcontribs)

Verdy’s examples mostly look fine on my machine, except for the Burmese. Try this:

Default font:

  • словѣ́ньскъ / ⰔⰎⰑⰂⰡⰐⰠⰔⰍⰟ
  • ꆇꉙ
  • မြန်မာဘာသာ
  • ქართული
  • සිංහල

Autonym font:

  • словѣ́ньскъ / ⰔⰎⰑⰂⰡⰐⰠⰔⰍⰟ
  • ꆇꉙ
  • မြန်မာဘာသာ
  • ქართული
  • සිංහල

On my Safari/Mac, all of the text displays correctly with the default font (and my installed fonts). Autonym font doesn’t render the cu-Glag and ii text (but does render cu-Cyrl). It breaks the display of ligatures in my text. It makes the ka and si text render in a clashing typeface.

The name словѣ́ньскъ should properly be rendered in a Slavonic font (Cyrs) – modern Cyrillic orthography (Cyrl) is foreign to this language. The top of cu.wikipedia.org links to the KurKlim font, whose copyright notice says Mia tiparo. Libere uzebla por chiuj (“My font. Freely available to all.” in Esperanto).

[Updated: changed format for font name UnicodeBMPfallbackSIL → Unicode BMP fallback SIL to make it work in Firefox, in addition to Safari and Chrome. Michael Z. 2013-11-18 16:07 z]

Verdy p (talkcontribs)

I also see these these texts displayed fine with the **default** fonts installed on my PC, but NOT when the font is forced explicitly to Autonym (via the CSS class).

Georgian and Sinhalese is also almost unreadable with the Autonym font, even if it can render it with big sizes. Hinting is the issue here, where some essential strokes are not visible at all at wiki default sizes (this should read OK for all sizes >= 10px, i.e. about 8pt on desktop/notebook, 6pt on smaller screens like smartphones).

Note: you include the additional font "UnicodeBMPFallbackSIL". This is stupid as this breaks completely the reason why this font was designed: reduced time and bandwidth to load many fonts in pages listing many language names. Don't do this! This class should only list that font (and should probably not even list the pseudo-font "serif" like it is in your message) !

The "autonym" class MUST reference only this font (plus "sans-serif": it won't break, if ever some other text like some wikitext gets rendered where only a language name should be shown, e.g. via a error in templates usage, or if the webfont is not loaded by the browser; "sans-serif" is the pseud-font used by default everywhere in MediaWiki). Note that the "Autonym" font is here a webfont coming from ULS, not your font "UnicodeBMPFallbackSIL", or the pseudo-fonts ("sans-serif" and "serif")

Mzajac (talkcontribs)

I include those fallback fonts for testing, so that any failures are evident.

“plus "sans-serif": it won't break” – yeah, that’s what the developers did, carelessly. Nothing appeared to break, so they went live with a feature without identifying basic failures. So don’t tell me what I’m doing is stupid.

Verdy p (talkcontribs)

I did not say that adding "sans-serif" was stupid, I understand the reason and gave it: the autonym webfont may not be loaded at all by browsers. What would be stupid would be to add your fallback font (or worse: other webfonts) in the list of fonts for the CSS class ".autonym" which must be retricted to use only .autonym {font-family: Autonym, sans-serif;} without anything else.

Mzajac (talkcontribs)

No, you are still misunderstanding.

I am saying that it is ineffective to test with font-family: Autonym, sans-serif;. When the Autonym font loads, any required characters that are missing from the font will be undetectable, because modern browsers will fall back to sans-serif, which, by Autonym’s design, will look pretty much like everything worked.

The only way to test whether Autonym renders all of the required characters is to add a visually contrasting font as fallback. So that gaps in its required coverage are evident. That is why I am testing with Unicode BMP Fallback SIL, which has full Unicode coverage and is not mistakable for any other font, and monospace, for everyone without that font installed.

The result is that in your sample above, all characters render and you can’t tell that anything is wrong with Autonym. In my sample, you can clearly see that Autonym is lacking glyphs for the Glagolitic and Sichuan Yi text.

Verdy p (talkcontribs)

I see now why you wanted to test it like that. Your first comment suggested to add these "contrasting" fonts in our CSS code on wikis, or directly on the "autonym" CSS class. Now I understand you want to test something else. Lets's return to the issue: - missing glyphs for some scripts - very poor hinting (even for Latin) for display on screen (it seems that the Autonym font uses in fact bitmap glyphs for low resolutions instead of hinting; I know that designing hinting in fonts is a complex task, still requiring costly professional font editors and skills; may be you should contact Michael Everson, member of the Unicode Consortium, which is also present on Wikimedia in the Language Comity; he's a great typographer that could help improve the rendering of this font)

Note that the Autonym font must be tracked for evolutions in the list of supported languages (this list is maintained by the Language Comity too), which will also decide on things like the text to display in code for their autonyms: each new supported language name should be displayable correctly with this font.

Mzajac (talkcontribs)

Here’s a screenshot of my sample above, on Safari 6.1/Mac, so you can see what I’m seeing.

Autonym font is not rendering the characters for Church Slavonic in Glagolitic script (cu-Glag), nor for Sichuan Yi (ii)
Reply to "Autonym font deficiencies"

How to use only input method and disable language selection module

2
Nasirkhan (talkcontribs)

I setup a wiki (http://bn.banglapedia.org) and there i need to use the 'Web Fonts' and 'Input Method' systems. I do not want to use the 'Language Selection' module. Even in the 'Web Fonts' and 'Input Method' i want to show the options for Bengali Language, and option for other language will not be displayed. So is there any way to configure the ULS like this?

This post was posted by Nasirkhan, but signed as Nasir8891.

Reply to "How to use only input method and disable language selection module"
117.195.59.215 (talkcontribs)

Hi, I came across one video clip for ULS help for Telugu language wikipedia as shown below. The clip is usefull but it does not show how to access help page. We will apreciate if some one helps us with simmiller clip for Marathi language.


Click on the 'cc to change the subtitle language and learn how to type in Telugu on Telugu Wikimedia projects from this video

This post was posted by 117.195.59.215, but signed as Mahitgar.

Mahitgar (talkcontribs)

This I have received for Marathi through other user support so closing this request. Rgds

Billinghurst (talkcontribs)

@Mahitgar: it would be worthwhile sharing your learnings here, as I am sure that other languages would be assisted by the generic process. It may even be worth creating a separate help page so that we can properly document the knowledge you have gained, and find it in a sensible search.

Reply to "Requesting video clip support"
2A02:8420:508D:CC00:56E6:FCFF:FEDB:2BBA (talkcontribs)

I known it may be the wrong place since most of the target glyph aren't part of any languages, or the languages are dead language. But it make a small issue here.

Nemo bis (talkcontribs)

You can try two things:

  • propose a good free font which includes those glyphs, for inclusion in ULS;
  • check in the Unicode standards if there is some special language code to which such glyphs could be suitably assigned.
2A02:8420:508D:CC00:56E6:FCFF:FEDB:2BBA (talkcontribs)

Ok All Those glyph can be displayed with http://users.teilar.gr/~g1951d/ which are all completely free without any restriction.
is updated regularly as the Unicode Standard evolve.

Again : those glyph aren't part of any live language (like ancient Egyptian Hieroglyphs)... and some aren't part of any language at all.

There is also this which allow to download the desired Unicode ranges from a font instead of the whole font.

Nemo bis (talkcontribs)

Thanks, that says the font is public domain. You can ask the font to be included for the languages with a language code, to start with. Then we can think what to do about the non-linguistic symbols...

2A02:8420:508D:CC00:56E6:FCFF:FEDB:2BBA (talkcontribs)

Some of the target languages are present on single font, but there's nothing in iso 639 for that. It would be easier to maintain since those fonts are updated/improved monthly. While it is an issue to load several languages at time on all pages, there won't be real problems, as the whole font weigh 1.6Mo in an HTTP request. It doesn't include non-linguistic symbols, Symbola would still be used separately.

I'm still suggesting "myn"; "egy"; "hlu"; "ssa"; "akk"; "aii"; and grc-dor since there's no standard for Doric Greek.

Reply to "Requesting support for more fonts."

Please allow us to disable this in preferences

2
Wikitiki89 (talkcontribs)

I am severely annoyed by this feature. It doesn't let me quickly see which languages a page is available in. The popup boxes for choosing a language and for the settings are way too big with way too much whitespace, making it inefficient to access information. But probably the most annoying part is that in the languages popup box, languages are not middle-clickable, meaning I can no longer browse through the languages and middle-click all the ones I want. In my mind, it would be a much better design to simply hide and show the languages within the sidebar itself and have them all function as ordinary links like they used to be. But if you can't do that, at least let us disable this in preferences so that we can just go back to seeing the full list of languages on the sidebar.

Santhosh.thottingal (talkcontribs)

Hi, You are referring to the compact inter language links beta feature which shortens the list of languags in the sidebar. This feature is a beta feature and by default it is not enabled. If you had enabled and did not like the feature, you can disable by going to Preferences->Beta section. For example, see https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-betafeatures

The language dialogue shown after clicking on ... button in the interlanguage links allows you to middle click. You can open it in new tab or hovering the link shows where it will take you.

Thanks.

Reply to "Please allow us to disable this in preferences"