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
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.
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
Hi, l10n people!
I came across an article [0] in my inbox this morning, and it linked to
an ECMA specification [1] that I think the i18n-oriented people (read:
the MediaWiki developers) in the audience may appreciate, especially if
you've tried to do something more complex with i18n on the client side.
In particular it looks like this spec encompasses a lot of things we've
written into our Language classes on the backend, that we can maybe now
get for free on the frontend. I'm particularly excited about the number-
formatting bits, which I'd asked about some weeks ago. The fundraisers
may enjoy the currency code validation, and I'm sure everyone can get
behind internationalisable Date objects with timezone handling!
Just a note to inform you - sadly this is all based on ECMAScript 5.1,
so we won't be able to use it universally anytime soon, but it seemed
like the sort of thing that we should keep an eye on.
P.S., I was sent the article by the wonderful new JavaScript Weekly [2]
list I've subscribed to, which has totally paid off so far. Interested
parties, subscribe away :)
[0] http://generatedcontent.org/post/59403168016/esintlapi
[1] http://www.ecma-international.org/ecma-402/1.0/
[2] http://javascriptweekly.com/
Cheers,
--
Mark Holmquist
Software Engineer, Multimedia
Wikimedia Foundation
mtraceur(a)member.fsf.org
https://wikimediafoundation.org/wiki/User:MHolmquist
Hello,
I would like to announce the release of MediaWiki language extension
bundle 2013.08
* https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2013.08.tar…
* sha256sum: 21b3abf3a8e19d0c746d41d246e4bc8883d0f5e179d894e1720500031c621f2c
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.
Kartik Mistry
== Babel, CLDR and LocalisationUpdate ==
* Only localisation updates.
== Translate ==
=== Noteworthy changes ===
* Initial translation area height is increased. With a higher
translation area it provides more space for suggestions.
* Bug 47861: Allow text selection in page mode of Special:Translate so
that parts of original message can be copied and pasted.
* Bug 46875: The tooltip highlighting the proofread action now appears
less often in incorrect places.
* Bug 36692: On language stats and message group stats, rows can no
longer get stuck in highlighted state.
* On translation pages, a "Translate" tab is shown instead of "Edit"
tab to improve usability and discoverability of the translation
functionality.
* Bug 49850: The page mode of Special:Translate parsed incorrectly
some square brackets as external links. Now it checks for supported
protocol before turning it into a link.
* Bug 52623: Discard changes button now works as expected in Google Chrome.
* Map 'be-tarask' language to 'be' language in Yandex machine
translation suggestion.
* Bug 52272: Assistant languages suggestions ('In other languages')
are no longer stripped of newlines.
* A step forwards for arbitrary source language for translatable pages
was taken. Translate now extension now respects the page soure
language returned by MediaWiki. There is still no user interface to
set the page source language.
* Bug 49326: Add "notify translators" link after marking page for
translation when TranslationNotifications is installed.
* Loading of message content now works correctly. It was broken with
namespaces which did not force capitalization of the first letter.
* Bug 52216: Special:AggregateGroups has now better group selector
which supports search.
=== Changes relevant to API users and developers ===
* Check for and disallow dynamic groups in ApiQueryMessageGroupStats.
* Reimplement beforeSubmit, afterSubmit and afterRegisterFeatures
hooks to support them in the new TUX editor.
== UniversalLanguageSelector ==
=== Noteworthy changes ===
* Added support for event logging. To use it you need to install the
EventLogging extension. The support is considered to be experimental.
To enable event logging, add following lines to your LocalSettings.php:
require_once "$IP/extensions/EventLogging/EventLogging.php";
$wgMainCacheType = CACHE_MEMCACHED;
$wgMemCachedServers = array( '127.0.0.1:11211' );
$wgEventLoggingBaseUri = 'http://localhost:8080/event.gif';
$wgEventLoggingFile = '/var/log/mediawiki/events.log';
To learn more about setting up EventLogging extention, see:
[1] https://github.com/wikimedia/mediawiki-extensions-EventLogging/blob/master/…
[2] https://www.mediawiki.org/wiki/Extension:EventLogging
* The libraries are loaded on demand, when they are actually used for
reducing traffic.
* Language settings are closed when clicked outside ULS langauge
selection window.
* Bug 50564: When the user makes changes in multiple modules and
clicks the Cancel button or closes the language settings after that,
cancel the changes in all the modules.
* Bug 50562: Canceling font change doesn't work for system font.
* Internal code changes to improve performance and make loading faster.
* Top position the ULS for IME menu with reference to the input field
instead of ... menu item to fix weird positioning at some places.
* Bug 51923: Use no-repeat follow url for background images to remove
possible duplicate images
* Fix wrong language comparison in webfonts so that expliticit
fontfamily style are not added to child elements.
* Use events instead of callbacks for success or no results in the ULS
search box. This allows extension users to bind for this event and
reduces callbacks.
* Use mw.hook for notifying cancel of settings window to modules.
* Documentation fixes.
=== Browser Blacklisting ===
* Currently, Internet Explorer < 7 is blacklisted for MediaWiki
version 1.22 and Internet Explorer 6 and 7 are explicitly blacklisted
for MediaWiki before version 1.22
=== Fonts ===
* Added Gentium font for Latin languages rich with diacritics like
IPA, Vietnamese and Polytonic Greek.
* Added Junicode font for Old English.
* Added Phetsarath font for Lao.
* Added lklug font for Sinhala.
* Added the Nuosu SIL font for the Yi language.
* Added Xerxes for for Old Persian.
* Added Shapour font for Pahlavi script.
* Added Nazli as a serif font for Persian script.
=== Input methods ===
* Bug fixes in Gujarati Phonetic, Gujarati Inscript 2, Punjabi
Phonetic and Oriya keyboards that didn't allow typing some characters.
* Added Kyrgyz Cyrillic keyboard.
* Added IPA X-SAMPA layout.
* Fixed the IPA-SIL layout: use the "modifier letter apostrophe" for
ejective consonants.
* Fixes ZWNJ character issues for Hindi and Marathi input methods.
* Updated Javanese keyboard.
* Removed outdated Myanmar keyboard.
--
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com
Hello,
This is a reminder that the Language Engineering team will be hosting
an hour long bug triage for R-T-L bugs later today, i.e. August 28,
2013 at 1700 UTC/1000 PDT on the IRC channel #mediawiki-i18n
(Freenode).
etherpad link: https://etherpad.wikimedia.org/p/BugTriage-i18n-2013-08
Thanks
Runa
---------- Forwarded message ----------
From: Runa Bhattacharjee <rbhattacharjee(a)wikimedia.org>
Date: Fri, Aug 23, 2013 at 11:56 AM
Subject: Language Engineering bug triage session for RTL language bugs
- Aug 28th 2013, Wednesday 1700 UTC/1000PDT
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>, Wikimedia
Mailing List <wikimedia-l(a)lists.wikimedia.org>, MediaWiki
internationalisation <mediawiki-i18n(a)lists.wikimedia.org>
Hello,
The Wikimedia Language Engineering team will be hosting a bug triage
session on Wednesday, August 28th 2013 at 17:00 UTC (10:00 PDT) for
some of the bugs that exist in languages written from Right-to-Left
(RTL). During this 1 hour session we will be using the etherpad
linked below to collaborate. We have already listed some bugs, but
please feel free to add more bugs (or file new ones!), and comments
about what you’d like to see addressed during the session. You can
send questions directly to me on email or IRC (nick: arrbee). Please
see below for the event details.
Thank you.
regards
Runa
=== Event Details ===
# What: Bug triage session for RTL language bugs
# Date: August 28, 2013 (Wednesday)
# Time: 1700-1800 UTC, 1000-1100 PDT (Timezone conversion:
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130828T1700
)
# IRC Channel: #mediawiki-i18n (Freenode)
# Etherpad: https://etherpad.wikimedia.org/p/BugTriage-i18n-2013-08
Questions can be sent to: runa at wikimedia dot org
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
Hello,
The Wikimedia Language Engineering team will be hosting a bug triage
session on Wednesday, August 28th 2013 at 17:00 UTC (10:00 PDT) for
some of the bugs that exist in languages written from Right-to-Left
(RTL). During this 1 hour session we will be using the etherpad
linked below to collaborate. We have already listed some bugs, but
please feel free to add more bugs (or file new ones!), and comments
about what you’d like to see addressed during the session. You can
send questions directly to me on email or IRC (nick: arrbee). Please
see below for the event details.
Thank you.
regards
Runa
=== Event Details ===
# What: Bug triage session for RTL language bugs
# Date: August 28, 2013 (Wednesday)
# Time: 1700-1800 UTC, 1000-1100 PDT (Timezone conversion:
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130828T1700
)
# IRC Channel: #mediawiki-i18n (Freenode)
# Etherpad: https://etherpad.wikimedia.org/p/BugTriage-i18n-2013-08
Questions can be sent to: runa at wikimedia dot org
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
Hi,
What is the right way to build jquery.ime with rangy for updating it in the
ULS extension?
I have the following simple script to do this:
===========================
#!/bin/bash
DESTINATION=/home/amire80/dev/livowiki/extensions/UniversalLanguageSelector/lib/jquery.ime/
rm -rf dist
grunt --force # --force is needed because of
https://github.com/wikimedia/jquery.ime/issues/249
rm dist/jquery.ime/jquery.ime.min.js
cp -rv dist/jquery.ime/* $DESTINATION
===========================
Is this the best way?
When I run it, grunt concatenates rangy to the end of the concatenated
jquery.ime, which is probably wrong because rangy is already there in the
ULS extension tree.
So:
1. Is concatenation needed at all for jquery.ime? We don't concatenate for
jquery.uls, but rely on ResourceLoader.
2. What is the right way to update rangy?
3. Is jquery.ime.min.js needed for anything? If it's not known to be useful
to anybody, can this be just removed?
Thanks!
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
Shamelessly looking at dialog code to lift, I came across WikiLove's dialog
box:
$dialog = $( '\
<div id="mw-wikilove-dialog">\
<h2><html:msg key="wikilove-get-started-header"/></h2> ...
Wait, html:msg ? It calls $dialog.localize() and the whole chunk of DOM
gets localized at once.
This has been in core since I believe 1.17, and the AFT, MoodBar, and
WikiLove extensions use it. I'm not sure why it's not mentioned in
Localisation <https://www.mediawiki.org/wiki/Localisation> or Manual:Messages
API <https://www.mediawiki.org/wiki/Manual:Messages_API> . I just added it
to Resource Loader modules
page<https://www.mediawiki.org/wiki/ResourceLoader/Default_modules#jquery.locali…>
.
Why isn't newer code using it, did it fall out of favor? E.g. Echo uses
jQuery chaining:
$( '<a>' ).attr(...).text( mw.msg( 'echo-overlay-link' ) ). ...
jquery.localize() doesn't give you the control of
mw.msg().escape/parse/plain/text() , but for big basic chunks of HTML it
seems ideal.
Thanks for any insight,
--
=S Page software engineer on E3
John Erling Blad, 12/08/2013 11:43:
> I was quite sure the "no" option was removed from preference after a
> discussion about this language code.
Seems not; probably that requires deleting the no language file and make
it into a dummy language? Dunno.
Nemo
>
> On 8/12/13, Federico Leva (Nemo) <nemowiki(a)gmail.com> wrote:
>> John Erling Blad, 12/08/2013 01:30:
>>> You can't use "no" as a language in ULS, but you can use setlang and
>>> uselang with "no" if I remember correct. All messages are aliased to
>>> "nb" if the language is "nb". Also at nowiki will the messages for
>>> "nb" be used, and this is an accepted solution. Previously
>>> no.wikidata.org redirected with a setlang=no and that created a lot of
>>> confusion as we then had to different language codes depending on how
>>> the page was opened. There are also bots that use the site id to
>>> generate a language code and that will create a "no" language code.
>>
>> This answers the question indirectly: as far as I know,
>> language-dependent content can, currently, be entered only in your
>> interface language. However, both no and nb are available in preferences
>> and you may also encounter
>> https://bugzilla.wikimedia.org/show_bug.cgi?id=37459
>>
>> Nemo
>>
>>>
>>> On 8/10/13, Markus Krötzsch wrote:
>>>>
>>>> What I wonder is: if users choose to enter a "no" label on Wikidata,
>>>> what is the language setting that they see? Does this say "Norwegian
>>>> (any variant)" or what? That's what puzzles me. I know that a Wikipedia
>>>> can allow multiple languages (or dialects) to coexist, but in the
>>>> Wikidata language selector I thought you can only select "real"
>>>> languages, not "language groups".
>>
>
