Talk:Universal Language Selector

Jump to navigation Jump to search

About this board

Madglad (talkcontribs)

Who has decided that Norwegian Bokmål should now be called "Norsk"? It was earlier called "Norsk Bokmål".

It is discriminating to select that one of the two equal and official writing norms of Norwegian (Bokmål and Nynorsk), the Bokmål, should be the one norm considered to be "Norsk".

Who took the decision, and where was it discussed in advance?

Jeblad (talkcontribs)

The language codes in a central file for Mediawiki was corrected, ie made in accordance with IANA registry for language codes, and as a consequence the language name for nowiki got changed. The longterm fix isn't to change the language name as some believe, the longterm fix is to correct the invalid language code used by nowiki. It is possible to make a temporal fix, but as it seems right now it won't be possible to do the necessary changes.

Madglad (talkcontribs)
Jeblad (talkcontribs)

Translations are in the CLDR. Please check out the old discussions.

BLÆGG (talkcontribs)

The Norwegian (bokmål)-project should be moved to the correct domainname (languagecode): nb.

None of the written forms of Norwegian have the right to call themselves «Norwegian» per se. This is an error that have to be fixed as soon as possible, as it violates Norwegian law.

There is a very little minority in Norway (less than 1-2 percent) that want to write in a language called «Riksmål», that is a Danish-Norwegian pidgin, and they are afraid they cant do that anymore if the domain is fixed, and the project-name is correctly changed. Thats the reason for why this hasn’t been done earlier.

Please make the change as soon as possible.

Reply to "Name of Norwegian languages"

Nastaliq font for Urdu

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, ? 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 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)
TheDJ (talkcontribs)
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 (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 post was hidden by C933103 (history)
2601:184:4180:8314:A588:2DA7:FAB2:34F0 (talkcontribs)
Reply to "Nastaliq font for Urdu"

I want to get labels and descriptions in all languages on Wikidata

Summary by Nikerabbit

Wikidata feature request.

Mautpreller (talkcontribs)

Instead, I get an absurd selection (most languages missing, but always Bavarian). What can I do to get _all_ labels and descriptions that exist and _none_ that don't exist? By default, please.

Nikerabbit (talkcontribs)
Mautpreller (talkcontribs)

To make it clear: for Q7731633, I get German, English, French, and Bavarian. This is nonsense pure and simple because Bavarian has not even a label or description. I have to select "all entered languages" to get a full list but Bavarian is still included. What I want is: On the page Q7731633 show me all labels and descriptions existing in all languages. I don't want to be forced to select "all entered languages" and I don't want "Bavarian" here because there is no information about this lemma in Bavarian. This is a very simple use case: I simply want to know what exists here.

Mautpreller (talkcontribs)

Doesn't work. I activated the LabelLister Gadget but Wikidata still shows an absurd selection only (including Bavarian, although there is neither a label nor a description in ths dilect). What do I have to do to simply get _all_ labels and descriptions in _all_ languages? Why isn't it possible to simply get all information available without pre-selection by an idiotic algorithm?

Mautpreller (talkcontribs)
Nikerabbit (talkcontribs)

You are asking for a feature (show all available languages) that is not related in Universal Language Selector. You should reach out to the Wikidata developers instead.

Mautpreller (talkcontribs)

Amazing that such a simple feature isn't thought of. Where do I find the WikiData developers?

Nikerabbit (talkcontribs)

I think best place is to discuss this in, or a feature request in Phabricator.

Kaldari (talkcontribs)

@Amire80: In the "ULS for editors" section, it says you can style text with different fonts, but the example doesn't work. Is that feature completely broken or just that font? Kaldari (talk) 18:25, 18 December 2017 (UTC)

Amire80 (talkcontribs)

It works at w:en:User:Amire80/Latf. Did you enable webfonts? Click on the gear icon -> Fonts -> Download fonts when needed. Unfortunately it cannot be on by default.

Kaldari (talkcontribs)

Nope, didn't do that! I'll add that to the documentation.

Reply to "Font styling doesn't seem to work"

Compact language links: language list with just the languages that are more relevant to you

Backinstadiums (talkcontribs)

Can I use this feaure in Wiktionary, choosing certain languages in a certain order?

Amire80 (talkcontribs)

It's already out of beta in Wiktionary. Perhaps you have disabled it in the preferences. You can re-enable it under the Appearance tab in the preferences. The preference name is "Use a compact language list, with languages relevant to you."

Backinstadiums (talkcontribs)

I cannot set it right for Wiktionary. Could you please post step-by-step guidelines to configure it as I please?

Amire80 (talkcontribs)

What do you mean by "set it right"? How do you expect it to be, and what do you actually see?

Backinstadiums (talkcontribs)

Searching for "a",, currently in the entry the content for 99 languages is unfolded. I'd like to restrict not only the number of languages but the order in wich they appear.

Amire80 (talkcontribs)

First, two questions:

  1. Do you have JavaScript enabled?
  2. In your Preferences, in the Appearance tab, do you have the preference "Use a compact language list, with languages relevant to you." enabled?
Backinstadiums (talkcontribs)

"Use a compact language list, with languages relevant to you." is enabled.

Regarding Java, do you mean in my browser?

Amire80 (talkcontribs)

I mean JavaScript, not Java. You can check it for example here. If you see "Yes" at the top of the page, then it's enabled.

Backinstadiums (talkcontribs)

Thanks for your patience with me. Yes it is. Next step then?

Amire80 (talkcontribs)

Sure, no problem. I want this to work well for everybody.

Can you please tell me which operating system and browser version are you using?

Backinstadiums (talkcontribs)

W7 home premium

chrome 62.0.3202.75

Yet I'd like to know where to select that "compact language list", and whether I can set a certain order of apperance for those languages.

Amire80 (talkcontribs)

OK, it should work well on this browser, so I wonder why do you see the list as unfolded even though you have the preference enabled.

Can you please turn of the JavaScript console by pressing F12 and check whether you see any error messages there when you open a page, for example ?

Backinstadiums (talkcontribs)
Backinstadiums (talkcontribs)

Is there any problem with the info. in the snap?

Amire80 (talkcontribs)

Strange. Nothing there looks broken. Just harmless warnings.

Can you please do this again, click "Default levels" next to "Filter", and select "Errors"?

Also, can you please go to w:fr:ASCII, and check whether you see the compact list with a "64 de plus" button, or a long list?

Backinstadiums (talkcontribs)

Hi again.

I can confirm errors is already selected.

Regarding the  "64 de plus", I can indeed select it,

Now, I've realized we can be talking about different issues. I am concerned about the languages offered for a certain entry in the English version of wiktionary. That is, for, there're 99 languages with the term "a" in their lexicon, all of them explained in the English language (for example, for french, the third etymology reads "third-person singular present indicative of avoir".

Yet, you could choose the French interface to see the same info.,

Now , I want to limit the languages which show the term that's been searched, not those of the interface offered on the lelft of the page.

Amire80 (talkcontribs)

Oh! Yes, we are talking about different issues :)

Compact Language Links is about the interlanguage links that appear on the sidebar. These are links to corresponding pages in editions of Wiktionary in other languages. This information comes from Wikidata.

You are asking about the page content in the English Wiktionary itself. Currently Universal Language Selector can't be used for this, at least not in a uniform way across all editions of Wiktionary. I agree that it would be a useful feature, but currently it's too complicated to do it. Perhaps developers of local gadgets in the English Wiktionary can address. The good long-term solution is putting lexical data in Wikidata, but that will probably take years.

Reply to "Compact language links: language list with just the languages that are more relevant to you"
Andrew Dalby (talkcontribs)

This language selector has replaced the languages I selected for displaying Wikidata labels and descriptions -- and those were the languages I used -- with "English", "British English". "French" and "Latina". Why? English, French and Latin are fine for me, but British English is useless, a total waste of space. There is no British English wiki. Why did someone decide I must have those four? I want to get "German" and "Portuguese" alongside "English" and "Latin" and "French". Why can't I do that? Why didn't this system take note of the choices I had already made or of the way I really work?

On the project page I see the words "you can also do a more detailed work for a single country, see for instance: bug T64346bug T141650bug T142070". Maybe I need to do that, but how? Following those links explains nothing.

I also see the words "ULS queries a service that determines your originating country based on your IP address". That doesn't seem to help me: I live in France. No sensible machine would imagine that two forms of English are among the three most important languages in France.

I also see the words "A small popup (technically called "undo popover" or "tipsy") will also appear when ULS changes the language compared to your previous setting". That would be nice, but it seems to be fantasy.

Nikerabbit (talkcontribs)

I am not sure why you are seeing those languages in Wikidata. For how to set languages for Wikidata, please see point number 2 in

As for your last comment, the popup only appears when your interface language is changed. That is not the same thing as the set of likely languages provided by ULS.

Andrew Dalby (talkcontribs)

<s>Thanks for replying. I did indeed set my languages, as indicated in your first sentence, and I have been using Wikidata with those language settings for a year or two. Those are the language settings that have now been overruled (for me). My Babel language choice is still correctly set on my user page -- with no mention of "British English" -- but it is being ignored. I naturally connected this annoying change with the fact that, above the box in which selected language labels and descriptions are shown on each Wikidata page, now appears the little word "Configure", which ls linked not to the FAQ page that you mention, or to my userpage, but to this "Universal Language Selector" page, which seems to be a long explanation of why configuring isn't possible for humans any more.

Perhaps I'm reading it wrong. But it is a plain fact that the language setting method that you mention has suddenly stopped working (for me) and that clicking on the new "configure" link brings me here.</s>

OK, but I just ran a test. I now claim on my user page to be a native speaker of all my languages. That would make me a very unusual person, but it has fooled the interface, which has given me back all my languages at the top of each Wikidata page (and British English is now omitted). Amazing! Sorry to have troubled you :)

Wargo (talkcontribs)

You confused ULS with selection of label languages and with babel languages (and there is language interface option too)?

Andrew Dalby (talkcontribs)

Could be.

Reply to "I want to delete British English"

Arabic Standard: ج and د are missing

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)


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

Please make the screenshots translatable

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)
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.


Siebrand (talkcontribs)
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.


  • 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"