Mediawiki-i18n May 2013

mediawiki-i18n@lists.wikimedia.org

12 participants
13 discussions

MediaWiki Language Extension Bundle launches
by Niklas Laxström 09 Feb '23

09 Feb '23

The Wikimedia Language Engineering team is pleased to announce the first release of the MediaWiki Language Extension Bundle. The bundle is a collection of selected MediaWiki extensions needed by any wiki which desires to be multilingual. This first bundle release (2012.11) is compatible with MediaWiki 1.19, 1.20 and 1.21alpha. Get it from https://www.mediawiki.org/wiki/MLEB The Universal Language Selector is a must have, because it provides an essential functionality for any user regardless on the number of languages he/she speaks: language selection, font support for displaying scripts badly supported by operating systems and input methods for typing languages that don't use Latin (a-z) alphabet. Maintaining multilingual content in a wiki is a mess without the Translate extension, which is used by Wikimedia, KDE and translatewiki.net, where hundreds of pieces of documentation and interface translations are updated every day; with Localisation Update your users will always have the latest translations freshly out of the oven. The Clean Changes extension keeps your recent changes page uncluttered from translation activity and other distractions. Don't miss the chance to practice your rusty language skills and use the Babel extension to mark the languages you speak and to find other speakers of the same language in your wiki. And finally the cldr extension is a database of language and country translations. We are aiming to make new releases every month, so that you can easily stay on the cutting edge with the constantly improving language support. The bundle comes with clear installation and upgrade installations. The bundle is tested against MediaWiki release versions, so you can avoid most of the temporary breaks that would happen if you were using the latest development versions instead. Because this is our first release, there can be some rough edges. Please provide us a lot of feedback so that we can improve for the next release. -Niklas -- Niklas Laxström

3 3

Report on WebFonts deployment
by Siebrand Mazeland (WMF) 20 Jan '14

20 Jan '14

Dear all, My apologies up front for the long e-mail that follows. In this e-mail you will find a comprehensive status overview of the recent WebFonts deployment. On Monday December 12 at 18:00 UTC we deployed the extension WebFonts[1] to 40 wikis in 11 Indic languages and Wikimedia Incubator -- all wikis in Assamese, Bengali, Gujarati, Hindi, Kannada, Marathi, Nepali, Oriya, (Eastern) Punjabi, Sankrit and Telugu have WebFonts now. WebFonts was not deployed on Malayalam and Tamil projects. The reason for this was that community members had requested us not to. We are confident that in time, the communities will request that WebFonts is enabled on their projects. WebFonts aims to resolve the issue that users see incomplete web pages, because the fonts to properly render the page is not present in the local system by downloading the font through the browser. One of our great challenges developing this functionality is the multitude of scripts and the low availability of freely licensed fonts that may be modified and redistributed. Over the past few months we have tried to build out a collection of fonts in the extension mainly for Indic languages, and we have performed many tests. We have solicited community involvement through messaging in village pumps, e-mails on mailing lists, blog posts on personal blogs as well as on the Wikimedia Foundation blog, at developer events, through personal e-mails and through our bug tracker, and gotten some feedback, although unfortunately not for all the languages we would like to have gotten it for. We will of course continue our efforts in this area. Next to the community involvement, we have had a two day session with the Red Hat Localisation team in Pune, India. Since the deployment, we have been criticised for not communicating enough -- or not through the right channels, not with the right people, not in time, or too soon, or not with the right messages. I'm not really sure how to respond to that, except for uttering a general "mea culpa, mea maxima culpa". We are working really hard in continuously improving the work that we do, and the way that we do it. We make mistakes, we are human after all, and when we become aware of our mistakes, we will do everything in our power to make it better. With our team we support the mission of the Wikimedia Foundation to "imagine a world in which every single human being can freely share in the sum of all knowledge." I care about that -- a lot. We all care, and I am pretty certain that we're not ignorant, dismissive or incapable. I acknowledge that we as the Localisation team are a relatively new entity within the MediaWiki development community and within the Wikimedia Foundation, with a very wide scope, and that we are dealing with a lot of technical details on which we are simply not able to assess the final quality; there are after all 7.500 languages in this world of over 7 billion people that we theoretically all cover, some 350 of those languages are supported in MediaWiki, and 280 within Wikimedia. I accept that we cannot keep everybody happy -- doesn't keep us from trying, though. I want to try and work with as many people as possible in a constructive way. With these numbers, that's not always easy to coordinate. To channel the input on languages, we have set up "Language Support Teams"[2]. We do not yet have a language support team for every language. Please sign up if you care about the technical facilitation of your language in the Wikimedia movement. Let's use the mediawiki-i18n mailing list[3] to have constructive discussions about language support. Let's use the #mediawiki-i18n IRC channel[4] on Freenode to have real-time discussions. Let's use bugzilla.wikimedia.org to report bugs[5]. Link [5] explains the bug reporting procedure. If you already know how, report issues quickly using this link: http://ur1.ca/6ov9a . Since the deployment, we have been made aware of about 17 issues. Some very serious in nature, others not requiring immediate attention. Yesterday an issue with web fonts not loading in Firefox was resolved in the infrastructure. Today around 15:30 UTC, we have deployed fixes for an additional hand full of issues[6]: functionality disabled in IE6, IE8 on Windows XP, selection buttons not working properly in IE7 and hiding the Samyak fonts in the font selector. During our current sprint, we are working on a framework for multi-lingual and localised user documentation as well as feature based feedback functionality for WebFonts, Narayam and Translate. In the future we will also explore what is known as "dark launch" by some, a kind of hidden live deployment of a feature, only usable be for example manipulating a URL. This would allow us to deploy a feature in a live environment, without having the "full deployment" impact. Thanks for reading through this. I am looking forward to working with you! Please read on for details on all the issues that were reported on WebFonts recently. Cheers! Siebrand Mazeland Product Manager Localisation Wikimedia Foundation ======================================= Links ======================================= [1] https://www.mediawiki.org/wiki/Extension:WebFonts [2] https://translatewiki.net/wiki/Language_support_team [3] https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n [4] https://translatewiki.net/wiki/Special:WebChat [5] https://www.mediawiki.org/wiki/Bugzilla [6] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106204 ======================================= Open issues ======================================= https://bugzilla.wikimedia.org/33004 -- Old cached pages do not have web fonts enabled Priority: HIGH -------------------------------------------------------------------------------------- Wikimedia is able to serve this many pages with relative few servers because of very aggressive caching strategies, especially for anonymous users. WebFonts requires the addition of JavaScript for anonymous users, which is not being done for pages that are in the squid cache at the moment WebFonts was enabled. All squid cache objects for wikis on which WebFonts was deployed need to be purged. An internal RT ticket created for the Wikimedia Operations team to get anonymous squid caches purged. This may take up to a week or longer to be resolved. https://bugzilla.wikimedia.org/33018 -- Firefox 5 on Windows XP has script time-outs Priority: MEDIUM -------------------------------------------------------------------------------------- The Localisation team has tested this report, and was not yet able to confirm the observation. The reason for using a non-recent version of Firefox for the report was the alleged lower memory usage. Brion noted that Mozilla has been actively working on lowering memory usage over the last year, so the reporter may be better off with the current versions than the old ones. https://bugzilla.wikimedia.org/33110 -- Google Crome on Windows XP dispays gibberish Priority: LOW -------------------------------------------------------------------------------------- Observed very rarely on a page on Wikimedia Incubator, and we have not been able to reproduce this observation, let alone reproduce it reliably. A screenshot is present in the bug report. Except for reporting upstream, no action is being taken on this issue at this point in time. https://bugzilla.wikimedia.org/33054 -- Hinting issues in Lohit fonts Priority: MEDIUM -------------------------------------------------------------------------------------- Confirmed in Windows XP. We can do something to the font by adding hinting, but this is a lot of work if it needs to be done manually. The stem of the Lohit glyphs could do with more width and darkness. This may not be desirable for platforms (Linux) which render it perfectly, because it already has hinting and anti-aliasing on an operating system level. Same goes got Windows 7. https://bugzilla.wikimedia.org/33100 -- Page crashes on Webkit browsers with WebFonts enabled. Priority: MEDIUM (could be HIGH if we find many occurances) -------------------------------------------------------------------------------------- A page in Nepali Wikipedia makes a tab on Mac OS X 10.7.2 with Google Crome crash. This behaviour was also reported for Mac OS X 10.7.2 (11C74) with Safari 5.1.1 (7534.51.22, r102522) [This is a webkit nightly build] by thedj. This is most probably related to the WebFonts code, because if, as a logged in user, web fonts is disabled in preferences, the page does not crash Chrome. Developer Derk-Jan Hartman was asked to report this bug in the WebKit. Please make us aware of any additional pages that would cause this behaviour in any wiki. https://bugzilla.wikimedia.org/33102 -- OSX 10.7.2/Opera 11.60 has no fallback for Latin characters Priority: MEDIUM -------------------------------------------------------------------------------------- This is a bug that needs to be reported upstream. No technical measures have been taken so far to mitigate this issue. One of the Localisation team members has been in contact with a high level executive of Opera, and will contact that person again. We're going to wait for a few days for an outcome -- if there is no expectation of a relatively quick fix, we might disable WebFonts for Opera completely. Opera unfortunately does not have a public bug tracker. https://bugzilla.wikimedia.org/33027 -- Narayam and WebFonts both loading slows down page Priority: MEDIUM -------------------------------------------------------------------------------------- The reporter claims that the functionality is quicker on translatewiki.netthan it is in Wikimedia wikis. A commenter states that more functionality usually means more code, means more data that needs to be transferred, and without changing bandwidth, that causes longer load times. This currently isn't our highest priority, but eventually we will look into this a little deeper. We're inviting volunteers to do some of the data gathering and analysis for us. What is needed in our opinion is insight in the data volume added by WebFonts, as well as an assessment of the code quality with regards to size optimisation. All referenced properly, of course :). There are alternate EOT conversion tools that have a good compression ratio. Needs to be explored, but EOT is not required for modern browsers since they started using WOFF fonts which are compressed OpenType fonts. https://bugzilla.wikimedia.org/33085 -- Integration of updated Lohit-Tamil Font Priority: MEDIUM -------------------------------------------------------------------------------------- Request to update WebFonts with a font that is updated upstream. This is something the Localisation team checks regularly. Will probably be closed this week, pending issues the have a higher priority. https://bugzilla.wikimedia.org/32942 -- Provide help page and bug report link for WebFonts Priority: HIGH -------------------------------------------------------------------------------------- More recently developed tools by the Wikimedia Foundation have often included feedback mechanisms. The Localisation team plans on implementing these for the functionality of the WebFonts, Narayam and Translate extension. Besides that, we also want to provide multi-lingual and localised documentation. This needs some thinking and some work to provide in a structured and navigable way. We'll keep you posted. It will most probably involve translatable *user* documentation on MediaWiki.org and hopefully it is possible to have one feedback location per feature across the multiple Wikimedia wikis -- this is something we're going to contact the ArticleFeedback and MoodBar teams for. ======================================= Closed issues ======================================= https://bugzilla.wikimedia.org/33025 -- When changing to a non-default web font, the content does not -------------------------------------------------------------------------------------- This issue was a side effect of a feature to allow multiple web fonts to be used using the "lang" attribute. It was resolved in https://www.mediawiki.org/wiki/Special:Code/MediaWiki/105980 and has been deployed. https://bugzilla.wikimedia.org/33034 -- Web fonts not loading in Firefox -------------------------------------------------------------------------------------- Duplicate reports were 33038 and 33044. This issue originated from http://www.w3.org/TR/css3-fonts/#same-origin-restriction. Almost all browsers except for Firefox ignore that specification. A fix was designed and deployed: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106092, https://gerrit.wikimedia.org/r/1501. Thanks to Roan, Brion and Ryan for their help. https://bugzilla.wikimedia.org/32775 -- Gibberish in Internet Explorer 8 on Windows XP -------------------------------------------------------------------------------------- This is an unexplained phenomenon only observed in Internet Explorer on Windows XP. It is also hard to reproduce. One of the developers was able to make something somewhat reproducible on a clean, fully patched installation of Windows XP with Internet Explorer 8. See bug report for details. Based on these observations we think it is a bad idea to keep supporting WebFonts in Internet Explorer 8 on Windows XP and we have disabled it in https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106172. This fix has been deployed. https://bugzilla.wikimedia.org/33096 -- Internet Explorer 6 does not have font fallback -------------------------------------------------------------------------------------- IE6 not having font fallback causes Latin characters to display as squares when a web font is loaded that does not contain glyphs for the Latin script. A screenshot is available at http://media.crossbrowsertesting.com/users/34057/screenshots/window/z669002…. Based on this observation, we think it is a bad idea to keep supporting WebFonts in Internet Explorer 6 and we have disabled it in https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106172. This fix has been deployed. https://bugzilla.wikimedia.org/33024 -- WebFonts menu buttons not working in IE7 -------------------------------------------------------------------------------------- This was caused by the JavaScript $( '<input type="radio" />' ) . attr( "name" ,"font"); not working in IE6 and IE7. Updating name attributes once they have been created is not possible. We think there may be more occurances of this in our code (one occurance in jQuery has already been identified: resources/jquery/jquery.validate.js:59). A fix was made in https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106175. This fix has been deployed. https://bugzilla.wikimedia.org/33040 -- Overlap in Samyak font for Hindi and Sanskrit -------------------------------------------------------------------------------------- This issue occurs in Windows XP and Windows 7 (possibly also in Windows Vista) when using Google Chrome. It is not observed when using Chrome with Mac OS X 10.7.2 or several Linux distributions (Debian and Fedora). Samyak Devanagari is available as a non-default web font in Hindi, Marathi, and Sanskrit. Samyak Gujarati is available for Gujarati as a non-default font. This font needs to be corrected. The maintainers will be notified of the observed issues, and mean while, the fonts will be removed from the WebFonts selection list (but can still be used using the font-family property. A fix was made in https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106179. This fix has been deployed. https://bugzilla.wikimedia.org/33039 -- Overlap in Madan font for Nepali -------------------------------------------------------------------------------------- This report was invalid. The reporter was not aware of the correct glyph for the Nepali script. Comments on this bug report resulted in two odd observations (Crome crash, Opera font fallback), that have been split off into separate bug reports: https://bugzilla.wikimedia.org/33100 and https://bugzilla.wikimedia.org/33102. https://bugzilla.wikimedia.org/33095 -- WebFonts menu can expand off the screen -------------------------------------------------------------------------------------- If the translations for "Select font" and "Login / Register" are really short, like in http://mr.wiktionary.org, expanding the WebFonts menu for anonymous users will display a menu that is partially off the screen. It was resolved in http://www.mediawiki.org/wiki/Special:Code/MediaWiki/106186, http://www.mediawiki.org/wiki/Special:Code/MediaWiki/106197, http://www.mediawiki.org/wiki/Special:Code/MediaWiki/106201, http://www.mediawiki.org/wiki/Special:Code/MediaWiki/106202. These revisions also depend on a few small UI changes of both WebFonts and Narayam, and will be deployed on December 19, 2011. <no bugzilla report> -- WebFonts menu expands under the control for customised input method in IE6 on transliteration -------------------------------------------------------------------------------------- There are issues with the z index in IE6. Because of https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106172, WebFonts is no longer available in IE6, so this issue is obsolete. Observing that the Hindi projects Wikipedia and Wiktionary are using an custom input methods tool, we would like to invite them to test Narayam which contains many input methods in a MediaWiki extension. We are very open to having the Hindi input method InScript tested and add a transliteration input method with some community representatives, as we have done with other Indic languages. We hope this will eventually lead to Narayam being adopted by the Hindi community, and the custom input method being abandoned.

8 8

Making inter-language links shorter
by Pau Giner 04 Sep '13

04 Sep '13

As multilingual content grows, interlanguage links become longer on Wikipedia articles. Articles such as "Barak Obama" or "Sun" have more than 200 links, and that becomes a problem for users that often switch among several languages. As part of the future plans for the Universal Language Selector, we were considering to: - Show only a short list of the relevant languages for the user based on geo-IP, previous choices and browser settings of the current user. The language the users are looking for will be there most of the times. - Include a "more" option to access the rest of the languages for which the content exists with an indicator of the number of languages. - Provide a list of the rest of the languages that users can easily scan (grouped by script and region ao that alphabetical ordering is possible), and search (allowing users to search a language name in another language, using ISO codes or even making typos). I have created a prototype <http://pauginer.github.io/prototype-uls/#lisa> to illustrate the idea. Since this is not connected to the MediaWiki backend, it lacks the advanced capabilities commented above but you can get the idea. If you are interested in the missing parts, you can check the flexible search and the list of likely languages ("common languages" section) on the language selector used at http://translatewiki.net/ which is connected to MediaWiki backend. As part of the testing process for the ULS language settings, I included a task to test also the compact interlanguage designs. Users seem to understand their use (view recording<https://www.usertesting.com/highlight_reels/qPYxPW1aRi1UazTMFreR>), but I wanted to get some feedback for changes affecting such an important element. Please let me know if you see any possible concern with this approach. Thanks -- Pau Giner Interaction Designer Wikimedia Foundation

11 15

MediaWiki Language Extension Bundle 2013.05 release‏
by Amir E. Aharoni 29 May '13

29 May '13

Hallo, I would like to announce the release of MediaWiki language extension bundle 2013.05 * https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2013.05.tar… * sha256sum: 9aea5b1dac2b38e44284373c849241fc694c78caff1d3ca3b4e6e72d66f2ab12 Quick links: * Installation instructions are at https://www.mediawiki.org/wiki/MLEB * Announcements of new releases will be posted to a mailing list: https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n * Report bugs to https://bugzilla.wikimedia.org * Talk with us at #mediawiki-i18n @ freenode Release notes for each extension are below. Amir E. Aharoni == Babel == Only localization updates. == cldr == CLDR was updated to version 23.1. == CleanChanges == Only localization updates. == LocalisationUpdate == No changes. == Translate == The new translation editor in Translate is now considered stable. The last month saw mostly polishing and bug fixes, changes in internals of the extension and terminology was made more consistent. Other notable bug fixes: * Warnings are loaded for outdated messages before user starts typing, because being outdated is an issue in itself. * Statsbar at the bottom floating bar of Special:Translate is updated when changing group. * Links of tabs at the top of Special:Translate are now kept in sync when changing message group or language * Custom icon (x) for clearing the searchboxsearch box clear icon was removed. Some browsers add this icon automatically, while others do not. * The tooltips for message groups in the group selector were removed. They contained unparsed wiki markup, which could be confusing. * Message documentation can be added even if the translations are restricted to only certain languages. * Icons for status markers and review actions for right-to-left languages were added. * In some rare cases the language name could be incorrectly displayed when selected from the language selector at Special:Translate, because the text direction attribute was not updated properly. == UniversalLanguageSelector == The last month saw significant changes in the Universal Language Selector extension: many bugs were fixed and some design changes were introduced. The default location of the language selectors is in the personal toolbar. For projects like Wikipedia, with interlanguage links, separating interwiki links from user interface language could cause confusion for users. It is now also possible to use a cog icon in the area for interlanguage links using $wgULSPosition = 'interlanguage' in LocalSettings.php, though this feature is still experimental. Notable bug fixes: * Major bugs in the input methods functionality for Microsoft Internet Explorer 8, 9 and 10 were fixed. * IME selector positioning is now more consistent: always under the input box, and matching the direction. * Anonymous users cannot change the user interface language if $wgULSAnonCanChangeLanguage is set to false. This may help avoid cache pollution in certain MediaWiki setups, while input methods and web fonts still remain available. * A link to open the ULS was added near the language selector on Special:Preferences. * The positioning of the ULS windows was cleaned up so that the appear in more predictable places on the screen. * ULS triggers are not displayed to users who disabled JavaScript or if the site has fatal JavaScript errors. * The checkbox that enables and disables webfonts was removed. The feature is now always on. * Any untranslatable elements have been made translatable. Please contribute to translations at https://translatewiki.net/wiki/Special:Translate/ext-jquery-uls and https://translatewiki.net/wiki/Special:Translate/ext-universallanguageselec…. * Fonts for the Syriac alphabet and support for the 'syc' language code were added. * Completely disabling input method tools and reenabling immediately was made easier. * The bubble for restoring the previous language is not displayed to anonymous users if they can't change the language. * jquery.i18n files can be loaded from the same domain to fix an issue with old Microsoft Internet Explorer versions. This is only relevant if resources are served from a different domain. A known issue is bug 48898 - the "Apply settings" button doesn't close the Input settings panel after enabling or disabling the settings. The settings are saved, but the button doesn't work correctly. Bugzilla link: https://bugzilla.wikimedia.org/show_bug.cgi?id=48898 Thank you, -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

1 0

Fwd: Problem with translated templates
by Guillaume Paumier 27 May '13

27 May '13

Hi, I'm having an issue with translated templates, and I'm not sure if it's a bug or just me being thick, so I'm hoping the i18n wizard can help me :) I've set up the following template for translation: https://meta.wikimedia.org/wiki/Template:Tech_header FuzzyBot has copied the source strings to the appropriate subpages, for example https://meta.wikimedia.org/wiki/Translations:Template:Tech_header/3/en However, https://meta.wikimedia.org/wiki/Template:Tech_header/en hasn't been created. This causes {{Translatable navigation template}} to fail and display a red link to [[Template:Tech_header/en]], which means I can't call the translated template. The same problem happens with https://meta.wikimedia.org/wiki/Template:Tech_news_nav I've temporarily reverted my edits to both templates because the problem was breaking pages (I couldn't use {{TNT}} because the /en subpage didsn't exist, but I couldn't use the normal template call either because it showed <translate> tags, so I reverted). Can anyone tell me what I'm doing wrong? -- Guillaume Paumier https://guillaumepaumier.com This is a mailing list-only e-mail address. Direct messages may go unnoticed.

3 2

[Language Engineering] Bug triage on Wednesday, May 29, 2013 at 1700 UTC/1000 PDT
by Runa Bhattacharjee 27 May '13

27 May '13

What: Internationalization bug triage Date: May 29, 2013 Time: 1700-1800 UTC, 1000-1100 PDT (Timezone conversion: http://hexm.de/r0) Channel: #mediawiki-i18n (Freenode) Etherpad: http://etherpad.wikimedia.org/BugTriage-i18n-2013-05 Questions can be sent to: runa at wikimedia dot org Hello, The Language Engineering team would like to invite everyone for the upcoming bug triage session on Wednesday, May 29, 2013 at 1700 UTC (1000 PDT). During this 1 hour session we will be using the etherpad listed above to collaborate. We have already listed some bugs, but please feel free to add more bugs, comments and any other related issues that you’d like to see addressed during the session. You can send questions directly to me on email or IRC (nick: arrbee). Please see above for event details. Thank you. regards Runa -- Language Engineering - Outreach and QA Coordinator Wikimedia Foundation

1 0

Assigning tags to extension messages
by Nick White 22 May '13

22 May '13

Hi, I have an extension (a skin, actually, but functionally it's exactly the same) which makes use of system messages to allow administrators to add extra content to some areas of wiki pages. So by default the messages are empty, and should never be translated. You can see this in the Erudite.i18n.php change at https://gerrit.wikimedia.org/r/#/c/62623/ I would like to mark these messages as not to be translated. It looks like one can do this within the mediawiki core using tags; http://www.mediawiki.org/wiki/Help:Extension:Translate/Group_configuration#… But I can't see an equivalent method for extensions. Does such a thing exist? I plan to mention in the 'qqq' entries that they shouldn't be translated, but it would be nice if they could be tagged so they weren't shown in the translation interface at all. If no such mechanism exists, what would be the best way of adding it? Using message documentation templates, or adding the possibility of something like a local mediawiki-defines.txt file for extensions? I don't know the i18n code very well, so perhaps there is a perfectly good solution I am missing. Thanks in advance, Nick

3 4

Re: [Mediawiki-i18n] [Commons-l] Enabling the Translate and UniversalLanguageSelector extensions on Commons
by Jean-Frédéric 20 May '13

20 May '13

Hi, I'd like to start a discussion about the merits and challenges of > enabling the Translate and UniversalLanguageSelector extensions on > Commons. > > The UniversalLanguageSelector extension ( > https://www.mediawiki.org/wiki/Extension:UniversalLanguageSelector ) > allows users to easily switch the interface language; it also embeds > an interface to enter text in non-Latin languages even if your > keyboard doesn't allow it. > > My feeling is that both these tools would dramatically improve the > user experience on Commons for people who don't use English. As a > multilingual wiki, Commons even seems like the perfect audience for > these tools. > FYI, I quick drafted < https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/UniversalLa… > in order to discuss the possible issues, then gain community consensus and hopefully get ULS enabled on Wikimedia Commons (I thought it was better to leave the question of the Translate extension to another discussion, as there seems to be more hurdles with the transition). Thanks, -- Jean-Frédéric

2 5

[Wikitech-l] GSoC - Prototype for jQuery.IME extensions for Firefox and Chrome
by Praveen Singh 13 May '13

13 May '13

Hi, I have made prototype extensions for Firefox and Chrome related to this project. These extensions port jQuery.IME completely to the client side and can be installed in the browser. These extension would allow users to use multilingual input methods on any website and not just on MediaWiki enabled websites. Source code and installation instructions are available at: https://github.com/pravee-n/prototype.jquery.ime Let me know if you have any queries. I would love to get some suggestions regarding how to improve these extensions.

1 0

I18n deployment 2013-05-07
by Niklas Laxström 07 May '13

07 May '13

When: Tuesday 2013-05-07 08:00 UTC What: * Run refresh-translatable-pages.php for remaining WMF wikis using Translate extension (mediawiki and meta were done last week). * Enable ULS for anonymous users without language selection. This brings web fonts and input methods to anonymous users on wikis which have ULS (meta, mediawiki, wikidata and couple of others). Tehnically: $wgULSEnableAnon is replaced with $wgULSAnonCanChangeLanguage. -Niklas

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Mediawiki-i18n May 2013