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.
Hoi,
Many of you are actively working on the localisation of MediaWiki. In the
last couple of days I blogged twice on possible maintenance jobs on your
local wiki.
There are two parts to it:
- the part where you copy messages to translatewiki; you have to be a
twn translator to do this
- the part where you remove messages on your local wiki; you have to be
a local admin to do this
The bottom line is that messages available at translatewiki.net will be
available on any Wiki. This is why you want to always localise at
translatewiki. When messages exist that are the same on your wiki and on
translatewiki they may cause problems in the future. This is why localising
locally is typically not the thing to do.
In the post a Toolserver tool is mentioned that makes it relatively easy to
do all this.
Thanks.
Gerard
http://ultimategerardm.blogspot.com/2012/02/cleaning-up-mediawiki-namespace…http://ultimategerardm.blogspot.com/2012/02/cleaning-up-mediawiki-namespace…http://toolserver.org/~robin/?tool=cleanuplocalmsgs
Le 17 févr. 2012 à 14:28, Bergi a écrit :
> Bináris schrieb:
>> An alternative solution to the original problem could be an extension that
>> displays possible characters from several alphabets and helps to generate
>> the username with mouse and put it back to the login name/password field.
>
> I don't think that would be a good idea.
> * It sounds as it would need JavaScript (or would be difficult to implement)
> * clicking is much slower than typing
> * "possible characters from several alphabets"? You know, we support the full set of Unicode. Displaying all unicode blocks would need the user to remember from which block his characters are
> * One version of the problem is that you try to login from a system that doesn't support your characters with any font. "displaying characters" is the heavy task. If we don't want to show pictures, the user needs to remember the individual character codes.
> (or is there a usable all-unicode web font?)
>
> Therefore, it is a great idea to login with your email address, which usually consists of latin characters. I have that problem myself, beeing User:✓ (a great challenge for toolserver tools ;-). Usually I have:
> * My browsers autologin function which fills in the username at known wikis
> * My browsers "notice" function which allows me to insert various texts with the contextmenu
> * Once logged in, I have a extraeditbutton above the edit form
> * or can c&p the sign from the #p-personal portlet (user page, user disk, prefs...)
> But when I try to login no at my home system, I'm challenged how to insert the 0x2713 char code with the keyboard. At windows Alt + num pad usually works, but... So I often end up googling for "unicode checkmark", and c&p the character from wikipedias "List of Unicode characters" :-(
Thank you for your support. I just submitted a complete patch entitled "Can't authenticate using my mother language username (UNICODE) when I only have (a public) access to Wikipedia with an ASCII (english) keyboard" in about 20 languages on
https://bugzilla.wikimedia.org/show_bug.cgi?id=34590
People supporting this idea, please for it.
Here is the text:
This is a real issue for people who have registered with a username having
UNICODE and non ASCII (7 bits) characters and who want to login to Wikipedia
when they are abroad with a simple English keyboard and want to edit some pages
(usually English pages).
The fact that Wikipedia and Mediawikis do not offer the possibility to
authenticate with an e-mail is now considered, at least for me, as a bug.
I recently discussed this fact on Wikitech-l ("Great idea"
http://lists.wikimedia.org/pipermail/wikitech-l/2012-February/058183.html) and
some tests have been made trying to answer legitimate questions (see
http://lists.wikimedia.org/pipermail/wikitech-l/2012-February/058253.html) to a
simple patch that I proposed.
This small patch in User.php (function idFromName) is enough in most cases:
$dbr = wfGetDB( DB_SLAVE );
$s = $dbr->selectRow( 'user', array( 'user_id' ), array( 'user_name' =>
$nt->getText() ), __METHOD__ );
if ( $s === false ) {
//Start Patch $result = null;
$stwo = $dbr->selectRow( 'user', array( 'user_id' ), array(
'user_email' => $nt->getText() ), __METHOD__ );
if ( $stwo === false ) {
$result = null;
}else {
$result = $stwo->user_id;
}
//End Patch
} else {
$result = $s->user_id;
}
The modified Login form is:
Username (or e-mail): |___________________|
Password: |___________________|
The full attached patch is rendering this new form in about 20 languages (that
is what we need in our wikis). The patch is simply adding two new msg:
- 'yournameoremail' instead of 'yourname' in Userlogin.php and
- 'passwordreset-usernameoremail' instead of 'passwordreset-username' in
SpecialPasswordReset.php .
In order to explain this new experimental feature, we added a Hook in
LocalSettings.php :
function efLoginFormMessage( &$template ) {
$template->set( 'header', "NEW (experimental): if you are a registered user
with an authenticated e-mail, you can also log in with your e-mail address in
place of your username. Your e-mail is used only during the authentication
phase; if successful you will be logged with your standard username. <br
/>Please notice that for people owning different accounts with the same e-mail,
you will be logged in with your first registered username (lowest ID). If the
password entered doesn't match the password of your lowest registered ID, you
can't authenticate this way and should enter your desired username.");
return true;
}
$wgHooks['UserLoginForm'][]='efLoginFormMessage';
I hope that this patch will be visited and accept. It is changing our live
here. People having been registered with accented characters or in Cyrillic can
use their e-mail to get their temporary password by e-mail while still being
able to sign authorship in Cyrillic or with accented characters avoiding the
English transliteration. Others still prefer the English transliteration, it is
a question of taste.
Without this patch, people are using the English transliteration for the
commodity of authentication.
Regards,
Nicolas
> Regards,
> Bergi
>
Hoi,
Today at 18:00 UTC (see also the link below) there is a Wikimedia Office
hour with the WMF localisation team. The subject is what more can we do for
your language. On my blog I entered some of the things we can talk about.
We also love to hear about how what we already do works for you and what we
(both you and us) can do to extend it further.
Joining our office hours is a great way to celebrate International Mother
Language Day.
Thanks,
Gerard
http://www.timeanddate.com/worldclock/fixedtime.html?hour=18&min=00&sec=0&d…http://ultimategerardm.blogspot.com/2012/02/international-mother-language-d…
---------- Forwarded message ----------
From: Steven Walling <swalling(a)wikimedia.org>
Date: 20 February 2012 23:17
Subject: [Foundation-l] Reminder: IRC office hours with the localization
team tomorrow
To: Wikimedia Foundation Mailing List <foundation-l(a)lists.wikimedia.org>
Hi all! Just a quick reminder that you're invited to join the WMF
localization team at 1800 UTC tomorrow.
---------- Forwarded message ----------
From: Steven Walling <swalling(a)wikimedia.org>
Date: Wed, Feb 1, 2012 at 10:46 AM
Subject: IRC office hours with the localization team, on International
Mother Language Day
To: Wikimedia Foundation Mailing List <foundation-l(a)lists.wikimedia.org>
Hi everyone,
I just wanted to give some advance notice about IRC office hours with the
localization team [1] at the Wikimedia Foundation, which will be aptly held
on International Mother Language Day.[2]
Date: 2011-02-21
Time: 18.00 UTC
Venue: #wikimedia-office
As usual, more logistical info and time conversion links are available on
Meta.[3] For a taste of what the localization team has been up to, I highly
recommend the blog posts they've been writing regularly.[4]
Thanks, and we'll talk to you later this month!
--
Steven Walling,
Wikimedia Foundation
1. https://wikimediafoundation.org/wiki/Localisation_team
2. https://en.wikipedia.org/wiki/International_Mother_Language_Day
3. https://meta.wikimedia.org/wiki/IRC_office_hours
4.
http://blog.wikimedia.org/c/technology/features/internationalization-and-lo…
--
Steven Walling
https://wikimediafoundation.org/
_______________________________________________
foundation-l mailing list
foundation-l(a)lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Hoi,
Several new developments have happened since the last update..
Members of the WMF localisation team have been to several conferences and
we discussed the notion of collaborating with several organisations on
collaborating on the shared needs for quality information about languages.
One of these organisations develops LibreOffice and, the person I spoke to
mentioned a project somewhere where people could enter data about their
language. The beauty of this project is that the data entered was used to
enable a language for OpenOffice and also creates the XML needed in the
format used by the CLDR.
On the subject of the CLDR, it is really painful when you have to append or
amend information. One of our developers found several errors in the names
of languages in his mother tongue and found himself unable to change them.
This seriously begs the question if the people of the CLDR are really
interested in providing a usable interface and get information on the 6000+
languages they still have no data on.
We have also reached out to all the Wikipedia communities to join us and be
part of a language support team for their language. Many languages are
supported in MediaWiki, some have a Wikipedia others are still in the
incubator but at this time we already 77 language support teams. This is
however only a fraction of the number of languages we do support. (there is
for instance nobody who is willing and able to support English .. :) ).
As it is so vital for a language to be available for use in software like
word processors and as we do need the information in MediaWiki as well, it
could be added as a requirement in the process of making a language
eligible for a project in the Wikimedia Foundation. Typically a first
project is a Wikipedia. Given that it is so hard, almost impossible to add
data to the CLDR directly, we need a plan. Maybe the project mentioned
above can help us out. One fringe benefit is that the people who are so
active in proposing new languages, languages they do not know according to
their Babel info, will have something that does show they are serious about
what they propose.
Technically in MediaWiki, more languages are getting support with input
methods and web fonts. The official language of Bhutan, Dzongkha, has
support in WebFont, this was one of the tangible results of the Pune
hackathon. It still needs review and it became available for review in
translatewiki.net. When we visited the offices of RedHat in Pune, we worked
on the input methods for languages like Punjabi and its documentation. The
benefit of working together is not just that things move faster but also
that the sharing of code becomes practical. With a shared code base, by
sharing tools, the results of the definition of input methods or web fonts
become available to many more people. This is where collaboration, this is
where Open Source really shines.
Thanks,
Gerard
http://translatewiki.net/wiki/Language_support_team
Because half of the localisation team is visiting Brussels in Belgium
because of FOSDEM event, the next next i18n deployment is going to
happen earlier on Monday, 1100 UTC if at all.
It's not yet fully decided what is going to be deployed. Given that
branching of 1.19 will happen soon, we probably deploy only small
fixes and the accumulated other changes will come when 1.19 is
deployed.
Some candidates are in
https://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/i18ndeploy
I'll keep you updated.
-Niklas
