list of supported languages

I was told that you could provide me a list of supported languages, do you have that ? --Zolo (talk) 18:14, 12 March 2013 (UTC)

No. I'll answer you there. Nemo 19:20, 12 March 2013 (UTC)

Inscript2 Input Method layout in Bengali

In input method of Bengali input at ULS I can watch Inscript2. What is the different between Inscript and Inscript2 ?? As per my knowledge four layout added in Narayam. Jayantanth (talk) 17:36, 7 June 2013 (UTC)

InScript 2 is a more recent not yet ratified (as far as I know) standard than InScript (1). See w:InScript keyboard for more details. siebrand (talk) 18:22, 7 June 2013 (UTC)

The most notable change in the inscript2 keyboard is the inclusion of 'Khanda-ta' ৎ, which is missing in the original inscript. (There were non-standard workarounds in existence which are inconsistent.) Besides the Khanda-ta, the new layout also includes ZWNJ and ZWJ which are to be used for writing non-combining consonant combinations and Ra-Japhala respectively. Runab WMF (talk) 14:36, 12 June 2013 (UTC)

Thanks all. Could you please merge the two layout and give only one inscript layout instead of two layout? Jayantanth (talk) 06:38, 13 June 2013 (UTC)

Unfortunately no. We will consider deprecating InScript (1) once InScript 2 is actually ratified. That's been in the works for years already, though. siebrand (talk) 12:58, 13 June 2013 (UTC)

Then My request: Please remove InScript (1) and show only InScript 2 (as Inscript). As I thought and Runa said that all latest update and implemented in InScript 2 as recommended by Govt of India in Bengali Inscript layout. . Previously Junaid added this JSscript to Narayam guided by me. Jayantanth (talk) 06:09, 14 June 2013 (UTC)

Inscript2 or Enhanced Inscript has not yet been completely ratified and officially announced by the GoI. As a result the originally released Inscript is still maintained as a fallback in most systems (Fedora follows this practice in ibus so that should be the case for distributions using the ibus input method). I would suggest to reconsider, because removing Inscript1 completely is not recommended and may end up confusing the users if Enhanced Inscript is churned any further and/or needs to be modified or pulled down. Runab WMF (talk) 21:21, 14 June 2013 (UTC)

Thanks Runa for clarifying me. Jayantanth (talk) 06:18, 15 June 2013 (UTC)

This was also filed as https://bugzilla.wikimedia.org/show_bug.cgi?id=49681 by the reporter. AKlapper (WMF) (talk) 01:04, 18 June 2013 (UTC)

And subsequently closed as WONTFIX. InScript 2 is a (proposed) standard that Wikimedia is not involved in. Changes should be proposed to the standards body, and alterantive key mappings are discouraged, because they'll be non-standard... siebrand (talk) 10:57, 18 June 2013 (UTC)

Font Problem in Tamil Wiki

After this implimentation, the default font of the tamil wiki is changed as "Lohit Tamil". This font is very small and little broken. can it be changed as "System font" as like earlier?? Arafath.riyath (talk) 11:18, 11 June 2013 (UTC)

I do agree with Arafath.riyath. The font “Lohit Tamil” does not give proper appearance. The previous default Tamil font (system font) is much better in terms of appearance and editing. Lohit Tamil could be option if anyone likes to use, but set Tamil system font as default. --Anton017 (talk) 12:14, 11 June 2013 (UTC)

Lohit Tamil is widely used in desktop linux distributions and the Android operating system. It's the de-facto open sourced font of choice for the Tamil script. In the web fonts of ULS we offer three more fonts for Tamil, as well as the choice to disable web fonts for Tamil. siebrand (talk) 14:25, 12 June 2013 (UTC)

Hi siebrand, Is it possible to keep system font (ta:File:Tamil_wiki_change_font.jpg) as the default font so that windows users will not be hindered by this change? Linux distributions and the Android operating system will not be affected because as you said “Lohit Tamil” is their system default font. Jayarathina (talk) 15:37, 12 June 2013 (UTC)

@siebrand, Request for Comment/Web fonts implementation for Tamil Wikimedia projects Arafath.riyath (talk) 04:59, 13 June 2013 (UTC)

Hello, I've read the whole page (not the Tamil talk, sorry) and in short it says 1) everyone could read everything before, 2) now nobody can't read anything; but I don't understand one thing: you seem to assume that everyone has the needed font installed locally.

What's this system font you're talking about, what operating systems have it/them installed? If everyone has it/them, how comes you have e.g. a "font help" link in the sidebar? Nemo 08:59, 13 June 2013 (UTC)

To @Nemo: No we are not able to read everything as before. The Tamil rendering is scrambled up in iOS 6 (iPad mini) (File:Tawiki-safari-ipad-mini.png) and looks ugly in windows too ( ta:File:Tamil Wiki Font Change.jpg ). I request you to read this Request for Comment/Web fonts implementation for Tamil Wikimedia projects, except for the first para, everything is in English there. Jayarathina (talk) 09:46, 13 June 2013 (UTC)

Nemo, System font is not the name of a particular font. It denotes any font that is set as the default font in a user's browser. If it is a Unicode font supporting Tamil users can read Tamil. Not being to read Tamil is not anymore a problem with modern browsers and latest popular mobile OS like Android and iOS. The font help page you see is a legacy page help page that is not updated for last 3 years. Yes, still there are problems for reading Tamil in few starting level gadgets and this web fonts implementation was done as a remedy to fix it. But, this has introduced new bugs and affected many other popular OS environments which were working fine already. This new implementation was not beta tested and the community was explicitly against its implementation for the last two years. Ravidreams (talk) 12:26, 13 June 2013 (UTC)

Jayarathina, I did read the page, I had a specific question about it.

Ravidreams, thanks, I know that by "system font" you didn't mean a specific font; I asked what font(s) are included in the operating systems, as you say Tamil fonts are widely supported, because I'm interested in knowing more about such fonts.

I'm glad to hear that the link in sidebar is useless for most people. Nemo 16:21, 13 June 2013 (UTC)

Nemo,

The "font help" link in the side bar is mostly the legacy of competing encoding standards in Tamil during in the late 90s and early 2000s. Since then unicode has become the standard tamil encoding system used everywhere. We have left the link in place for the sake of some gadgets.

Lohit Tamil is completely unsuited for Windows and that is where the vast majority of machines that access Ta wiki projects use. The unsuitability of Lohit Tamil is well known to Siebrand and Santosh. It was the very reason Webfonts was not rolled out in Ta wiki before. We have gone through this process once already. All we ask for is making "system font" option default and for the few people who dont have the system font installed (Latha in case of windows and Lohit Tamil in case of Ubuntu, Android and some other linux distros) they can go through the font help link and enable webfonts.

You can see the freaked out reaction of the community - this is not something people will get used to. It is makes site practically unreadable. Sodabottle (talk) 13:32, 13 June 2013 (UTC)

For Tamil, default font changed to system font in https://gerrit.wikimedia.org/r/#/c/68350/ Santhosh.thottingal (talk) 13:41, 13 June 2013 (UTC)

Santhosh, thanks for making the change.

1. When can we expect the change to go live?
2. Will the page load slow down bug remain even after making system font as the default? I mean will the web font script be downloaded even if the system font is the default? If yes, then it should be rectified and the web font script be triggered only upon choosing the web font from the drop down.
3. The language icon setting is missing in few pages. See bug number 7 here.
4. Suppose we make a new web font created and made available through services like http://www.google.com/fonts/ and https://typekit.com/ , can that be used in Wikipedia? Technnical aspects and licensing fee aside, is it philosophically aligned to be used within a Wikipedia project? Since only the content is under Creative commons license and we are not distributing the font, should the font be also under a Wikipedia compatible license?
5. It is better if the language setting icon is placed to the top right corner of the site or on that top row with clear label that says as "langauge and font settings". Even experienced Wikipedians are unable to find where the icon is located and how to change it. It is as good as hiding that icon. Besides, other languages section is a navigational aid and should not be coupled with a setting for user control. Ravidreams (talk) 06:46, 14 June 2013 (UTC)

The change went live a couple minutes ago, I now see ta.wiki using my system font. Nemo 08:17, 18 June 2013 (UTC)

Requesting link to the content language wikipedia help page

Hi,

Narayam used to have a provision for link to help page. Marathi language wikipedia we used use the linked page with keyboard layouts and other helpfull information for Marathi language typing + FAQs in Marathi.

Since "Online screenboard" feature is still not available link to help page is requested.Please let us know if we need to file a bug.

Rgds Mahitgar (talk) 09:36, 12 June 2013 (UTC)

This feature request is being tracked as bugzilla:42373. siebrand (talk) 08:37, 21 June 2013 (UTC)

Think we should make a list of bugs raised for ULS and give a link to that list and that would be more helpful than a help link, so that poor users get to know what wont work first and don't wast their valuable time. Deepugn (talk) 13:37, 21 June 2013 (UTC)

The list is linked from the extension's page: . Nemo 17:10, 21 June 2013 (UTC)

Links to help pages seems to have got activated,Nice of you. thanks Mahitgar (talk) 10:51, 18 July 2013 (UTC)

feature to make content language input default

Thanks for all your efforts to make ULS user friendly.

At Marathi language wikipedia since time of 'Narayam' we were looking for a feature to make Marathi as default content language for certain pages (like sand box etc) and/or certain namespaces. 'Narayam' could not do that , would it be possible with ULS ?

If yes then let we know we can file a bug at bugzilaa.

Regards Mahitgar (talk) 09:43, 12 June 2013 (UTC)

In MediaWiki, content pages always have the wiki's content langauge by default. By using "<div lang="code">...</div>" you can ensure that text is tagged properly, and that web fonts are applied to parts of text as expected. For inline words, do not use "div" but use "span". Some wikis have the template {{Lang }} for this.

If you meant something different, then please describe what it is exactly you are after. siebrand (talk) 14:23, 12 June 2013 (UTC)

Sorry for delay in the reply, Since, June month is begining of academic year and admissions period for majority of our users, hits had gone down and it was defficult to ascretain exact response to ULS on Marathi language Wikipedia.Since end of June user activity is coming back to normal. I have tried to analyse data from 24 June 2013 to 10th of July 2013. All this is about using ULS for inputting Marathi language which has been our real and majior concern.

|-

! New users inputting Marathi Data

!Number of Users success in inputting Marathi

! Those who used Roman script to type Marathi

! Marathi people who used english

|-

|1)Newbies with account+ips first timers,typing effort other than special sandbox page

|37

|10

|15

|-

|2)Newbies with account+ips first timers,typing effort on special sandbox page

|10

|28

|17

|-

|Totals Row1+Row2

|47

|38

|32

|}

• Row1:
  • Newbies with account Contribution is sourced and counted from [http://mr.wikipedia.org/wiki/Special:Contributions/newbies
  • ip contribution is sourced from [http://mr.wikipedia.org/w/index.php?title=Special:RecentChanges&hideliu=1
  • Newbie+ip efforts to contribute while creating very short new pages and stopped by edit filter are considered
  • First timer ips are guessed from their lack of skill level with wikimarkup
  • Whether user/ip is of Marathi background is guessed from user name or content wordings
• Row2:
  • Figures sourced from Hits catched by special purpose edit filter no 56, to the special sandbox,(Sandbox to practice inputting Marathi language) New users and ips get diverted with from welcome message and or mediawiki message to above mentioned special Sandbox
  • Since people are self selecting to reach out to special sanbox that means they are specifically intrested in learning Marathi typing input skills
• Above figures are for rough idea and can ip figures can not be exact due to related technical aspects.Detail study page at marathi wikipedia is http://mr.wikipedia.org/wiki/विकिपीडिया:मराठी_भाषेच्या_वापराबद्दल_धोरण/अभ्यास
• For inputting text Marathi language wikipedia initially used to use local java to provide transliteration, there after we shifted to Narayam , Now since begining of June 2013 we are using ULS.
• If you see above figures now new user success ratio to input Marathi is around 40%
  • While we did not do such exercize earlier I have been personally creating all related help pages, (We have put in substantial effort for the same) and studying new user behaviour extensively I feel there is substantial improvement in success rate of users becoming able to input Marathi with help of new ULS,nodoubt compliments and thanks for the same.
  • Rest of 60% are also serious potential users, currently an user needs to select language of input; what we are requesting is to provide us facility where in ULS Marathi transliteration अक्षरांतरण can be made default on the special sandbox page विकिपीडिया:धूळपाटी/केवळ_मराठी on Marathi Wikipedia so first timer need not select language of input.

Hope and request to look into above.

Thanks and Warm regards Mahitgar (talk) 12:35, 11 July 2013 (UTC)

Additional information on input methods usage pattern among Marathi People on internet from online survey. Sample size is very small but still can put some light on some of the finer aspects

|-

! Marathi unicode input systms used by online users

! percentage of users per system

|-

|Tell us how to type

| 9%

|-

|Want more info

|18%

|-

|Whichever Marathi language website we visit we use their local transliteration system

|39%

|-

|Windows IME/inscript

|6%

|-

|Baraha transliteration

|3%

|-

|Google Trasnliteration

|22%

|-

|GaMaBhaNa Transliteration

|1%

|-

|}

• Above figures highlite the fact that current online usage of inscript wont be beyond 10%.Most of Marathi language websites provide nongoogle-transliteration that roughly translates around 45% users, roughly 25 % users use google transliteration.Roughly 30% people still find it defficult to aquire the input skill.

• Even after extensive descriptive and practicle support on Marathi Wikipedia 40% people find it difficult one more reason is many of them are coming with Google Marathi search and are used to Google transliteration system which is bit different than rest of transliteration systems.Rest of transliteration systems for example if I type letters bit rest of transliterators will do bब iइ t ट one letter against one letter instead what google transliterator does is it transliterates word by word, eg after typing complete word 'bit' usually I will press shift key for space and google provides transliteration only after pressing of the shift key so the user has a feeling transliteration happens word by word and automatically. When such users aproach on Marathi wikipedia they realise that is not happening they might be hoping that transliteration automatically would happen once they save button.
  • Rest of Marathi language website also Marathi input transliteration is default so new users end up wondering why they are not getting Marathi out put on Marathi wikipedia ?
  • Our rest of experinced users at times swmts usually delete such contributions as spam or vandalism and new user dosent get enough further opportunity to experiment although he is willing thats why he reaches to special sand box. Now what we need is an input system that is default for the given page or may be an input box so the user understands that here on wikipedia transliteration operation happens bit differently that google transliteration.
  • And this is what makes me think that since bult of the users are transliteration users online lay out for this purpose would benefit them or link to a help page Mahitgar (talk) 15:55, 11 July 2013 (UTC)

Hi, Thanks for these information, but would you please point out whether you need any improvements or changes in our typing tools based on this data? We are working on having help links to all input methods in ULS. The help pages will have keyboard layouts. See this example. On-screen keyboards are planned. It will take some time to get ready.

If you need any improvements in the tools, Bugzilla is the most appropriate place to report. Thanks. Santhosh.thottingal (talk) 04:47, 12 July 2013 (UTC)

Hi, Thanks for your positive response. Let me list all my wish list here for my own convinience and then file the bugs one by one.

1) When not-logged in (ip) user goes to language >> language settings >>Display language (which he currently can not change without being logged in) >> if he selects link log in and logs in >>Requested enhancement : ULS language setting displya should be open next to MediaWiki:Loginsuccess or best thing is link of ULS language setting in MediaWiki:Loginsuccess to all the users

• Purpose: To complete users expected logical next step of action of language selection in smooth manner.

2)For not logged in users (in non VE environment) MediaWiki:Anoneditwarning should display ULS - selction of input method option list for content language in an horizontal manner (to save the space) since currently sign apearing in a distant corner of edit window is not a clear enough indication to a new anon user.

• Purpose in those namespaces where VE support is not available

3) In VE pagesettings>>languages below MediaWiki:Visualeditor-dialog-meta-languages-section the option button should be available 'Visit ULS language settings' for current {{contentlanguage}} wiki >> Then dialog box of ULS language settings should open up

4) a: Currently language list displayed below MediaWiki:Visualeditor-dialog-meta-languages-readonlynote/mr does not open the respective language wiki but when that is possible along with that respective language item ULS should offer option to open up the respective language wiki with related display and/or input .May be this shall need to mingle three extensions VE,wikidata,ULS and also

4)b When in menubar languages displayed by wikidata if curser hover over any wiki language name options as requested in 4a should display and available. Mahitgar (talk) 03:12, 13 July 2013 (UTC)

The above message is not opening for further editing so adding the further list here

5) All wikis,other than english wikipedia ULS input options for input should be availabe as dropdown menu on VE toolbar File:VisualEditor.toolbar.png just below the page settings with sign + eneble input methods/'select input method'/name of current selected input method as heading.

6) When curser hovers over sign it should display text select your input method

7) currrent 'control+m' toggel option is available but is usefull in between selected language keyboard and pc-native keyboard, one more toggle option for bilingual usage like say japanese and sanskrit, this option would be benefitting for wiktionaries.

8) Narayam used to have colour for edit window when typing is on, ULS language settings should offer 3 colours user selectable options for edit window,

8) Make available facility to make ULS input default for special sandbox page for practice

9) Enhance Extension:InputBox with a special 2 new parameter 1) input-language-code 2) Input method from ULS; so these input boxes can be used on input practice page as well as usefull to most language learning articles on various wikibooks Mahitgar (talk) 06:04, 13 July 2013 (UTC)

Thanks for the bug reports. We have triaged some and will be triaging the rest them shortly. Some of the requests need consultations and we'll be updating more information through the relevant bugs. Do feel free to let me know if you need any assistance about Bugzilla. Runabhattacharjee (talk) 11:14, 15 July 2013 (UTC)

Thanks for your nice support. Triaging is understandable process,I am sure all of you are giving your best. Since VE will begin soon on rest of language wikis we are more concerned about Bug no.49569

Thanks again and best wishes Mahitgar (talk) 03:56, 17 July 2013 (UTC)

Adding fallback fonts instead of overriding the site

The extension seems to override editors’s choices set in the site’s CSS. Wouldn’t it be better if this added additional fallback fonts at the end of the font stack, instead of stealing control from the editor? Example: If the reader has the right font installed, this should display w:fraktur text.

style="font-family:UnifrakturMaguntia, UnifrakturCook, Unifraktur, serif;"

Keinen Unparteiiſchen wird der Einwand ungläubiger Theologen: wenn es Typen geben ſolle, ſo müſte ihre Abſicht von den Zeit­genoſſen ſchon erkannt worden ſehn, ſonderlich beunruhigen können.

But on en.Wiktionary, if I tag the language as German, then the fraktur font choice gets overridden by the default sans-serif font. Sometimes I actually see a flash of the fraktur text, but then it seems the JavaScript loads and changes it.

lang="de" style="font-family:UnifrakturMaguntia, UnifrakturCook, Unifraktur, serif;"

Keinen Unparteiiſchen wird der Einwand ungläubiger Theologen: wenn es Typen geben ſolle, ſo müſte ihre Abſicht von den Zeit­genoſſen ſchon erkannt worden ſehn, ſonderlich beunruhigen können.

Even if I correctly tag it with a fraktur script code lang="de-Latf", it still renders incorrectly on en.Wiktionary.

lang="de-Latf" style="font-family:UnifrakturMaguntia, UnifrakturCook, Unifraktur, serif;"

Keinen Unparteiiſchen wird der Einwand ungläubiger Theologen: wenn es Typen geben ſolle, ſo müſte ihre Abſicht von den Zeit­genoſſen ſchon erkannt worden ſehn, ſonderlich beunruhigen können.

Previous discussion on en.Wiktionary.  —Michael Z. 21:19, 14 June 2013 (UTC)

Funny. On this site all three examples displayed with the correct font when I previewed my post and after I saved it. Now, a few minutes later, only the first example honours the fraktur font selector. —Michael Z. 2013-06-14 21:30 z  —Michael Z. 2013-06-14 21:30 z 21:30, 14 June 2013 (UTC)

Please vote for Bug 54453 - Don’t override site authors’ styles by using inline style.  —Michael Z. 2013-09-22 18:10 z 18:10, 22 September 2013 (UTC)

Buggy implementation of ULS in commons

Trying to continue the discussions happening here, since it was polluting the original intention of the bug https://bugzilla.wikimedia.org/show_bug.cgi?id=49560 ULS was buggy when it was put in commons, The preferences were not getting saved until the page was refreshed. Changing the input methods was one of the main features of ULS and that was not working when implemented in commons initially, how ridiculous. Hope you can think how a common user would feel when he changed his preferences and seeing it is not applied, defenitely it was a bug and a very serious one. I definitely understand and agree to the point that there are no softwares without issues, but to find a software which dont serve the purpose it was made for is very rare and i found one in the initial implementation of ULS in commons. We had a discussion among admins in malayalam wikipedia and even withdrew ULS implementation request from malayalam wikisource since the admins were convinced that ULS was buggy at that time. I am not sure how such silly buggy things can come into mediawiki, i would like to say things like this is making mediawiki unreliable for the common mass and we feel things are not going right. Deepugn (talk) 02:37, 18 June 2013 (UTC)

I'm not sure what bug you're talking about, but you have 37 edits on Commons; the Commons community didn't have any problem with the enabling of ULS, which was very smooth for them. Nemo 06:48, 18 June 2013 (UTC)

http://www.mail-archive.com/mediawiki-commits@lists.wikimedia.org/msg62076.html

can you please comment on this one, if you would be kind enough to explain what was fixed there? Deepugn (talk) 08:21, 18 June 2013 (UTC)

You're making a problem out of issues that were discovered and then resolved, and all that was almost a month ago? It's more productive to discuss the current situation, if any. siebrand (talk) 10:53, 18 June 2013 (UTC)

Hi Siebrand,

I could have raised it here a month ago but I wanted to convince people from the community, we had a discussion about this in malayalam wikipedia admin group. Since the guys were convinced that the commons implementation was buggy , we withdrew ULS implementation request in malayalam wikisource, you can verify that.

I just wanted to make people know that ULS was implemented in commons when it was seriously buggy and not properly tested.

I am not trying to make any problem, I was trying to put this into every one's notice so that developers avoid such carelessness in future so that they don't destroy the goodness of a great application.

I thought I had the right for my voice, but you guys are labelling me a problem maker! cool! Deepugn (talk) 11:19, 18 June 2013 (UTC)

bugzilla:48703 doesn't say what you described above. You say "I wanted to convince people from the community", I hope that you used actual facts. Nemo 12:33, 18 June 2013 (UTC)

This is what happens, when some points out you guys call them thugs or say you are disconnected from community, like in the case of Praveens's bug.

If you have doubt you can check with the malayalam community and clear your doubt. When i asked you did not even care to explain what was fixed and instead tried to blame me of not using actual facts Deepugn (talk) 14:50, 18 June 2013 (UTC)

"When i asked you did not even care to explain what was fixed": false, you didn't ask what was fixed. Are you interested in knowing? Here's the list of what has been fixed so far in the last few weeks after Commons deploy:

• MediaWiki_1.22/wmf4#UniversalLanguageSelector
• MediaWiki_1.22/wmf5#UniversalLanguageSelector
• MediaWiki_1.22/wmf7#UniversalLanguageSelector Nemo 15:18, 18 June 2013 (UTC)

Thanks Nemo, yes i am interested in knowing.

actually i did ask what was fixed, and i wanted to know what was fixed in that particular commit.

http://www.mail-archive.com/mediawiki-commits@lists.wikimedia.org/msg62076.html

can you please comment on this one, if you would be kind enough to explain what was fixed there?

Deepugn (talk)‎08:21, 18 June 2013 Deepugn (talk) 16:22, 18 June 2013 (UTC)

Sure, that was after saying something horrible had been fixed; we still don't know what's the bug you're talking about.

For future cases, when you know the commit, the bug number is in the commit message ("Bug: 48703") and it's also linked if you visit gerrit (gerrit:65101). Nemo 16:38, 18 June 2013 (UTC)

Hey i wanted to know the about this diff, i think this was the bug i was talking about, if you could explain me what was fixed here -

https://git.wikimedia.org/blobdiff/mediawiki%2Fextensions%2FUniversalLanguageSelector/170be2068e6dfe216609a839de334d71faedf961/resources%2Fjs%2Fext.uls.ime.js Deepugn (talk) 02:01, 19 June 2013 (UTC)

I told you, it's described on bugzilla:48703#c0. In short ULS was contacting the server too often; probably this meant that for users with slow machines (like mine ;) ) selecting an input field (like the search bar) took some fraction of second more than needed, or something like that. Nemo 07:44, 19 June 2013 (UTC)

Please see this screen recording,

http://www.youtube.com/watch?v=oiAc27mYYDQ

am i using ULS in the correct way, or did i make a mistake? Deepugn (talk) 17:18, 19 June 2013 (UTC)

Ah, at last! The 8th message contains the issue. :)

So your problem is that, after selecting a keymap in a language, selecting one of the "Other languages" in the keyboard icon doesn't switch to a keymap for that language but keeps the previous one? I don't know if it's already filed as bug, if not please report. Nemo 07:31, 20 June 2013 (UTC)

Ha ha Nemo!, thanks for being kind to listen and being patient unlike the others. I would say this is another one.

I am also interested in the testing procedure happening there, before putting actual extensions and features in live wikis? I am just surprised, all this turning out to be very different from how I thought it was!! Deepugn (talk) 08:07, 20 June 2013 (UTC)

On the general procedures, you can see there's a lot of work going on: Language Testing Plan. You can help by describing test that should be performed regularly, I think: see Quality Assurance/Browser testing/How to contribute.

For specific issues, however, it's simple, for all users: even if you don't plan to help systematically, you can be of great help if you just use the tools normally and immediately report the problems you find, being focused (specific and detailed, not vague or offtopic): see How to report a bug. Nemo 14:07, 20 June 2013 (UTC)

Popup in edit box is not completely visible

If lower part of the edit box is not in the view, the popup of Universal Language Selector come from topright of the editbox (instead of lower right) and points upright. But it is larger than the area in top region of the browser, and only half of it the popup is visible. Vanischenu「mc|Talk」 11:14, 21 June 2013 (UTC)

Thanks for your report. This issue was tracked as bugzilla:49679. It was marked as resolved 2013-06-26 12:44:49 CEST and will become available on Wikimedia wikis in the next week. siebrand (talk) 16:52, 27 June 2013 (UTC)

Disabling ULS

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 Patrick87 (talk) 00:15, 28 June 2013 (UTC)

Yes. See Universal_Language_Selector/FAQ#How_can_I_disable_Universal_Language_Selector. siebrand (talk) 13:29, 28 June 2013 (UTC)

Thanks, but this only allows to disable "input methods", not ULS completely. I hope there is more I can do? Patrick87 (talk) 14:03, 28 June 2013 (UTC)

No. Nemo 09:54, 30 June 2013 (UTC)

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. Patrick87 (talk) 14:08, 30 June 2013 (UTC)

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? Drajay1976 (talk) 04:29, 5 July 2013 (UTC)

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! Patrick87 (talk) 10:02, 5 July 2013 (UTC)

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? Eloquence (talk) 08:14, 8 July 2013 (UTC)

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. Patrick87 (talk) 09:59, 8 July 2013 (UTC)

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. Nemo 08:17, 9 July 2013 (UTC)

I fully agree with your concern. I do not agree with you that the Churchill invocation is applicable. siebrand (talk) 08:25, 9 July 2013 (UTC)

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! Patrick87 (talk) 16:24, 1 August 2013 (UTC)

The new Persian and Arabic Fonts

Hello, Many other users and I have been having trouble with the recent changes to the Arabic and Persian fonts that have been made system-wide now. This issue affects many people. Arabic Amiri - The problem with this font is that it is simply too hard to read, and is better suited for Qur'an verses rather than an official encyclopedia like Wikipedia. It also bogs down on system resources, because it has to load the default Arabic font, and THEN the Amiri font, which can take up to a minute depending on article length. Minimum time I have experienced on Chrome latest version quad core processor is 5 seconds, but that is the bare minimum (as in, an article maybe about an Arab person and the name transliterations having to load) Persian (unknown font) - This new font is okay, it is MUCH more readable than Amiri, but not better than the previous one, which was clean and easy-to-read. Again, though, it BOGS down on my system as well as many others. Please bring back the old fonts, or make these new fonts optional and make the old ones default. For all of the Middle Eastern community on here, thank you. We would very much appreciate it. 75.167.5.217 11:33, 4 July 2013 (UTC)

Hebrew font problem

It appears that the extension uses a certain sans-serif font for Hebrew that is very bad at displaying nikud. Some fonts that are good at displaying nikud are: David, Narkisim, SBL Hebrew. Most others, especially sans-serif fonts, are terrible at it. Can this issue be resolved? There is no problem with displaying Hebrew on any computer since Windows XP, so maybe there is no need for a web font at all. Or if there is, can it be a font that displays properly with nikud? Ynhockey (talk) 13:15, 10 July 2013 (UTC)

IPA input

Hi, it's good to have an input method for IPA but why is it placed in English? It would make more sense to have IPA inputs in a separate "language". Also, is it not possible to have other input methods, such as X-SAMPA (I did not know this SIL keyboard before and I'd rather use one I know)? How difficult is it to add an input mapping? Darkdadaah (talk) 15:18, 10 July 2013 (UTC)

You can submit a mapping yourself, may not be too hard: see Extension:Narayam#Developing_a_key_mapping. Nemo 16:03, 10 July 2013 (UTC)

Ideally I should just have to copy the SIL mapping. I'll see what I can do when I have some time. Darkdadaah (talk) 09:28, 11 July 2013 (UTC)

The specification for an input method is given at https://github.com/wikimedia/jquery.ime/wiki/Technical-Specification#input-method-definition

Reading some existing input methods will give understanding too. Thanks Santhosh.thottingal (talk) 07:53, 12 July 2013 (UTC)

Thanks, I just found the Sil-IPA input method: https://github.com/wikimedia/jquery.ime/blob/master/rules/fonipa/ipa-sil.js

Let's say I create an X-SAMPA mapping, is there a way to submit it to be used on Wikimedia sites (or just individual sites)? Darkdadaah (talk) 14:07, 13 July 2013 (UTC)

Teamwork Barnstar

• Teamwork Barnstar

		The Teamwork Barnstar
		Hi, This is a Barnstar for all those developers who worked on MediaWiki software and various MediaWiki extensions. Special mention to VisualEditor, Universal Language Selector, Edit Filter as milestones which help achieve wiki moto access for all, and many more extensions which are user friendly. Thanks to all you developers.

Mahitgar (talk) 03:50, 17 July 2013 (UTC)

Thank you very much, Mahitgar. We very much appreciate the acknowledgement. siebrand (talk) 23:35, 24 July 2013 (UTC)

Old English Wikipedia

Hello. Can someone more knowledgable please comment on a ULS-related discussion on angwiki? Would it be practical to add a rune keyboard mode, even though the default OE script is Latin-based? πr² (t • c) 17:43, 21 July 2013 (UTC)

You should file a bug requesting this. If you have the ability or can find someone on angwiki with the ability, adding a rune keyboard mode is much more likely if they can help the l10n. ☠MarkAHershberger☢(talk)☣ 02:40, 23 July 2013 (UTC)

bugzilla:51917 πr² (t • c) 13:09, 24 July 2013 (UTC)

Several problems with web fonts

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. Olaf Studt (talk) 09:11, 5 August 2013 (UTC)

As for case sensitiveness, you should just make the template convert to lowercase with the {{lc:}} magic word. Nemo 12:58, 5 August 2013 (UTC)

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. Mps (talk) 07:56, 6 August 2013 (UTC)

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. Nemo 14:17, 6 August 2013 (UTC)

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. Mps (talk) 15:19, 6 August 2013 (UTC)

Again, I never said "lowercase everything". Your point is very clear and I'm unable to comment it, no purpose in repeating. Nemo 15:24, 6 August 2013 (UTC)

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 Santhosh.thottingal (talk) 04:25, 8 August 2013 (UTC)

How do I provide guided tour for ULS

This post by Nemo bis was moved on 2013-09-20. You can find it at Extension talk:GuidedTour/Archive2/Flow export#c-Mahitgar-2013-09-19T11:45:00.000Z-How_do_I_provide_guided_tour_for_ULS. Nemo 16:34, 20 September 2013 (UTC)

Numeral system

Devanagari numerals (१, २,...९) are default when you select Hindi irrespective of different options (BolNagri, phonetic, inscript, etc). In reality, Indo-Arabic numerals (0, 1, 2,...9) are used in Hindi newspapers, magazines, text books, government publications, etc. It really get on nerves if you want to write something in Hindi on Wikipedia because you have to switch over settings so many times. So it would be really helpful if developers could provide options for selecting numeral system also. Regards. Bill william compton (talk) 05:12, 14 October 2013 (UTC)

Well it is for Hindi Wikipedians to discuss but with simple Control+M you can toggle (shift) between the scripts Roman and Devnagari. I do not think you need to switch over settings so many times. I tested १1२2३3४4 for Hindi लिप्यंतरण option just now. with ease I did १Control+M1२Control+M2३Control+M3४Control+M4 १1२2३3४4 it did not take many seconds. In any case you use shift button for some letters simillerly you are using Control+M instead so it does not increase many strokes. Seondly if you have an entire different keyboard for roman numeral+ hindi alphabates to type १1२2३3४4 this you will end up switching key boards. So rather using Control+M seems more logical to me still it is for majority of hindi wikipedians to decide and request the changes. Still I suggest a revisit to your request Mahitgar (talk) 08:53, 6 August 2014 (UTC)

How can I provide a more focussed way of changing the interface language?

Background: I am using ULS on a bilingual wiki (English/Hebrew, not that it matters). Some page content is in Hebrew, some in English. I want to give users the ability to change the interface language, but all I really care about is switching between these two languages. Is there any way I can, say, put in the sidebar a link called "English" that just changes the interface language to English, and one called עברית that just changes the interface language to Hebrew? The full power of the ULS "Languages" tool is way overkill for me. Barring this, is there any way I can set the initial choices in the "Languages" tool? Right now people looking for Hebrew for the first time must do a search, etc. If I could at least be sure that the two languages I care about are presented initially, it would be a good start. Thanks very much. http://horawiki.org/ MediaWiki 1.21.1 Larrydberg (talk) 00:05, 28 October 2013 (UTC)

OK, I managed this one myself, and I'll record the solution here in case it helps anyone else. The goal is to provide links that switch interface language without changing the current page. I put these links at the top of the sidebar; you can see them at http://horawiki.org/ (a link "עברית" that switches to Hebrew) and http://horawiki.org.il/ (a link "English" that switches to English).

1) On MediaWiki:sidebar, add line "switchlanguage|otherlanguage"

2) MediaWiki:otherlanguage contains the word "עברית", MediaWiki:otherlanguage/he contains the word "English"

3) MediaWiki:switchlanguage contains "{{canonicalurl:{{FULLPAGENAME}}|setlang=he}}", and MediaWiki:switchlanguage/he is the same except with setlang=en

4) To make the system access language-dependent versions of MediaWiki:switchlanguage, put "$wgForceUIMsgAsContentMsg = array('switchlanguage');" into LocalSettings.php

This seems to do it. Improvements or suggestions gratefully accepted.

The initial language choices in the Languages tool can be manipulated with a tiny modification to routine getFrequentLanguageList in UniversalLanguageSelector/resources/js/ext.uls.init.js, but this is a terrible idea since changes there are overwritten with the next release. Larrydberg (talk) 23:39, 30 October 2013 (UTC)

What is the status of permitting anonymous users to switch interface language?

The current documentation is very confusing. I read somewhere that it's a bad idea to do this, because then caching will cause some people to see the wrong language, and there's no plan to fix this. I read elsewhere that all cacheing can be disabled, solving the problem. I'd really like a definitive answer on what can go wrong when I permit anonymous users to change interface language, and what if anything I can do to ameliorate it. I should mention that I have a very low traffic wiki and don't need any cacheing at all. Related comment: Suppose I'm a logged-in user with a language set in my preferences, and I use the "Languages" tool to change the interface languages. This seems to change the language in my preferences, i.e., the change is persisted. Is this intentional? I'd like to suggest that it's the wrong behavior. I often want to change interface language temporarily for whatever reason, but would prefer my base language (as set in preferences) not to be altered when I do this. Thanks for any help. http://horawiki.org/ MediaWiki 1.21.1 Larrydberg (talk) 00:11, 28 October 2013 (UTC)

You don't seem to be using squid or anything, are you? Then ULS just works for everyone, as on translatewiki.net (you can see its configuration files online). With squid, varnish etc. ULS just doesn't work; this has never progressed at the WMF because those who manage the caching system and those who develop ULS never reached an agreement on the appropriate solution, so it was never developed. I don't know if there are news from WMF.

As for temporary language changes outside preferences, that's what the uselang trick is for. Nemo 06:06, 29 October 2013 (UTC)

No, not using squid/varnish, so maybe things are OK as they are. I use explicit setlang in URLs via .htaccess, so that the initial language is set correctly based on domain even for anonymous users, e.g. http://horawiki.org.il/ sets Hebrew as the default. I was perhaps confused by the discussion here where the conclusion is that setlang only works part of the time. Anyone know if this bug has been fixed?

You might also look over my solution to my own problem, just below, to see if there's anything I'm missing. Larrydberg (talk) 23:24, 30 October 2013 (UTC)

That wiki doesn't use the UniversalLanguageSelector but the old LanguageSelector. Nemo 05:56, 31 October 2013 (UTC)

Say what? By "that wiki" you mean http://horawiki.org/? Maybe this is part of my problem; I'd like to understand it. What is "the old LanguageSelector" and how do I get rid of it? I've installed the ULS and my LocalSettings.php contains

$EXT = "$IP/extensions";

require_once( "$EXT/UniversalLanguageSelector/UniversalLanguageSelector.php" );

$wgULSPosition = 'interlanguage';

Does this not do what I want? Larrydberg (talk) 12:07, 31 October 2013 (UTC)

Sorry, I meant: the wiki you linked [[Extension talk:LanguageSelector/Flow export#c-Amqui-2013-02-12T05:35:00.000Z-{{#switch:en|_doesn't_work_for_log-out_visitor|a discussion about]]. Nemo 17:15, 31 October 2013 (UTC)

Nastaliq font for Urdu

RESOLVED

Tracked in Phabricator Task T58939 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.

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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... Syed Wamiq Ahmed Hashmi (talk) 21:33, 6 November 2013 (UTC)

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. Nemo 22:32, 7 November 2013 (UTC)

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. Syed Wamiq Ahmed Hashmi (talk) 12:45, 8 November 2013 (UTC)

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. Nemo 23:40, 8 November 2013 (UTC)

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 (talk) 16:40, 11 November 2013 (UTC)

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 (talk) 17:29, 11 November 2013 (UTC)

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 ? TheDJ (talk) 11:14, 12 November 2013 (UTC)

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. Nemo 17:40, 12 November 2013 (UTC)

@Nemo_bis Doesn't NafeesWeb have the exact same license though ? http://www.cle.org.pk/software/localization/Fonts/nafeesWebNaskh.html TheDJ (talk) 10:47, 14 November 2013 (UTC)

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? :) Nemo 15:25, 14 November 2013 (UTC)

Well that information isn't in the ticket that I read. It is however hidden in the commit message. TheDJ (talk) 13:37, 15 November 2013 (UTC)

Not sure if this is still an open issue. Could Noto be a possible free font?

https://www.google.com/get/noto/#nastaliq-aran 2601:184:4180:8314:A588:2DA7:FAB2:34F0 (talk) 16:09, 15 November 2018 (UTC)

Its free. 103.94.130.3 103.94.130.3 (talk) 11:33, 14 March 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Autonym font deficiencies

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)

    සිංහල Verdy p (talk) 22:12, 8 November 2013 (UTC)

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. Santhosh.thottingal (talk) 04:46, 9 November 2013 (UTC)

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.  —Michael Z. 2013-11-09 16:41 z 16:41, 9 November 2013 (UTC)

 —Michael Z. 2013-11-09 16:59 z 16:59, 9 November 2013 (UTC)

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]  —Michael Z. 2013-11-09 17:38 z 17:38, 9 November 2013 (UTC)

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") Verdy p (talk) 18:34, 11 November 2013 (UTC)

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.  —Michael Z. 2013-11-14 16:13 z 16:13, 14 November 2013 (UTC)

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. Verdy p (talk) 20:49, 15 November 2013 (UTC)

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.  —Michael Z. 2013-11-18 15:56 z 15:56, 18 November 2013 (UTC)

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. Verdy p (talk) 23:18, 18 November 2013 (UTC)

Here’s a screenshot of my sample above, on Safari 6.1/Mac, so you can see what I’m seeing.  —Michael Z. 2013-11-18 16:05 z 16:05, 18 November 2013 (UTC)

Design considerations regarding usage of Autonym font in ULS

The Autonym font is currently developed to be able to display all glyphs of all language Autonyms with the purpose to be used by ULS for language Autonyms The question is: Does this really make sense? Do we really need a font that supports all glyphs? Wouldn't it make much more sense to design a font that only contained glyphs potentially missing in the system font? E.g. Latin glyphs should be available in the system font on all systems if I'm not mistaken. Why do we add those to the Autonym font? Currently this causes already many bugreports because of a lack in font quality. Even if this is resolved the glyphs used in Autonym font will differ from the system Font of most OSes (e.g. Latin charakters contained in Arial on Windows look considerably different to the latin charakters of Autonym font). Therefore we're creating an inconsistent look of texts in the UI on purpose. Is this really what we want people to see in prominent spots when visiting Wikipedia? Patrick87 (talk) 17:37, 9 November 2013 (UTC)

No. This font is clerly NOT designed to support all glyphs needed to render any supported language.

For example it MUST NOT be used to display translations. Its purpose is to display only the native language names, exactly those returned by {{#language:code}}, and only those texts! Its purpose is to allow correct visual identification of languages.

In addition it must be able to render any language code, i.e. lowercase letters a-z, digits 0-9 and the minus-hyphen '-' (needed for language variants)

It may render the uppercase letters, allowed as equivalents for language-codes in BCP47 for use in the lang="" attribute, or any language code supported by Mediawiki on Wikimedia sites, though Wikimedia sites should only use lowercase letters for these codes). For this reason it will include the full printable ASCII range (U+0020..U+007E, i.e. 95 glyphs only); it should probably not include punctuations of ISO88-59-1 or windows-1252 outside ASCII.

The number of needed glyphs is then capped, and is not very large (limited to the list of supported languages).

But if we remove the ASCII characters then the ".autonym" CSS class should contain "font-family: Autonym, sans-serif". But some languages will render inconstantly when some characters are found only in the "Autonym" font, others being in the browser's default fonts for "sans-serif". Their glyph metrics won't match together.

So if we ever remove ASCII charcters from the "Autonym" font, then we MUST remove also all Latin letters, so that they will be all fond in the browser's default fonts for "sans-serif". Caveat: the metrics of Latin letters (in "sans-serif") may no longer match with metrics of other characters needed for other scripts (this will be a problem in case of dual scripts in one language name). So let's keep ASCII completely in that font, with other those Latin letters needed for supported language names.

My opinion is that "sans-serif" is present in the CSS class only for the case where the browser does not load the webfont from ULS, but it should NEVER be used if the Autonym webfont is loaded: the webfont must be complete for all supported languages, even if some of them may be rendered corectly only with the browser's default "sans-serif" font list.

It is absolutely not critical that the Autonym font looks different for displaying languages from the various fonts used for displaying the rest of pages or the UI, as long as it remains in a coherent sans-serif stroke style (for Latin, Cyrllic, Greek), or the default stroke styles most commonly used to display other scripts.

But I agree that all the supported glyphs in the Autonym font should have correct metrics, and good hinting for all resolutions (including small sizes >= 8px, as low as possible). Note that this font should be available in bold and italic for some UI cases (bold needed when the language name is selected in the current page, in a language bar.

Navigation language bars at top or bottom of pages (linking to translated version of the current page) should be deprecated as much as possible : the ULS should be used instead for selecting the page to render, written directly in the language selected for the UI. Pages can autodetect this language (including for their templates), using "autotranslation" based on {{int:lang}} (for example with LangSwitch on Commons or Meta, or with the translate extension). Verdy p (talk) 18:59, 11 November 2013 (UTC)

SidebarTranslate

See w:Wikipedia:Village pump (proposals)#Make SidebarTranslate into a gadget for a discussion about a very interesting user-script (which I've been using and appreciating for a few months). The script takes the interlanguage links, and

1. translates them using the built-in title-text (thereby showing the English name for each), and
2. adds a link to GoogleTranslate for each respective article (so with 1 click, I can see the German page machine-translated, for example).

The first aspect might be useful to think about integrating with ULS as a preference option. The second aspect is very handy for power-users, but obviously couldn't be incorporated as a mediawiki default as it endorses a single service, and might lead to more newcomers trying to submit machine-translated articles (which is generally discouraged). (Note that the script's js was rewritten a few weeks ago, so it should be extra-efficient and clean at the moment. :) Thought for food. –Quiddity (talk) 21:06, 9 November 2013 (UTC)

Is there some expression that evaluates to the current language?

E.g., something like {{CURRENTLANGUAGE}} that gives me the code for the current interface language? Background, in case there's another solution: My wiki is multilingual. I use categories heavily, for example Category:Dances. The text at the top of that page should be displayed in the current interface language. So on that page I put {{int:CategoryDancesHeader}} and create pages MediaWiki:CategoryDancesHeader/XX as appropriate. This works fine. For Hebrew I also must set the overall right-to-left orientation of the page. On a normal page I do that by putting {{PAGELANGUAGE:he}} at the top. But that doesn't work in this case. It looks like setting PAGELANGUAGE on a page doesn't effect pages into which that page is transcluded. A solution is to set PAGELANGUAGE at the top of Category:Dances itself with something like {{PAGELANGUAGE:{{CURRENTLANGUAGE}}}}. How can I get my hands on the current language in order to do this? I'd also think this functionality is useful enough to be provided directly, e.g., let {{SETPAGELANGUAGECURRENT}} to set the page language to the current language. Larrydberg (talk) 07:55, 13 November 2013 (UTC)

No, there isn't. The request to add one has been rejected/delayed many times because it would allegedly break Wikimedia projects' caching system, see bugzilla:2085. Wikis are using a hack which achieves the same effect anyway (so allegedly breaking thier cache, but nobody cares), that is a custom message Lang called with int magic word, which will return the language code of the user's interface.

I can't tell if it's the appropriate solution for you, but you can do the same or locally hack your MediaWiki installation as e.g. translatewiki.net does (I think some patches were published on the bug or elsewhere). Nemo 08:03, 13 November 2013 (UTC)

Edit diff that had made ULS non-functional on mr -wiki

Hi, Probably this edit difference had made ULS icons were not apearing to enable and ULS became non functional in important edit fields until the edits to MediaWiki namespace were reverted today. Since edit making admin was not aware of technical aspects about enabling new gadgets, suitable technical guidance , if any will be welcome. Mahitgar (talk) 10:36, 28 November 2013 (UTC)

Gadgets provide such powerful functionality they can break all MediaWiki JavaScript, including UniversalLanguageSelector's. The best advice we can give is to enable the gadgets one by one, to find the one that breaks pre-existing JavaScript functionality. After finding the culprit, that one can be debugged, and remain disabled. siebrand (talk) 11:01, 28 November 2013 (UTC)

Thanks and Rgds Mahitgar (talk) 13:46, 29 November 2013 (UTC)