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
Hi everyone,
as some of you might know, I'm a software developer at Wikimedia
Deutschland, working on Wikidata. I'm currently focusing on improving
Wikidata's support for languages we as a team are not using on a daily
basis. As part of my work I stumbled over a shortcoming in MediaWiki's
message system that – as far as I see it – prevents me from doing the
right thing(tm). I'm asking you to verify that the issue I see indeed is
an issue and that we want to fix it. Subsequently, I'm interested in
hearing your plans or goals for MediaWiki's message system so that I can
align my implementation with them. Finally, I am hoping to find someone
who is willing to help me fix it.
== The issue ==
On Wikidata, we regularly have content in different languages on the
same page. We use the HTML lang and dir attributes accordingly. For
example, we have a table with terms for an entity in different
languages. For missing terms, we would display a message in the UI
language within this table. The corresponding HTML (simplified) might
look like this:
<div id="mw-content-text" lang="UILANG" dir="UILANG_DIR">
<table class="entity-terms">
<tr class="entity-terms-for-OTHERLANG1" lang="OTHERLANG1"
dir="OTHERLANG1_DIR">
<td class="entity-terms-for-OTHERLANG1-label">
<div class="wb-empty" lang="UILANG" dir="UILANG_DIR">
<!-- missing label message -->
</div>
</td>
</tr>
</div>
</div>
This works great as long as the missing label message is available in
the UI language. If that is not the case, though, the message is
translated according to the defined language fallbacks. In that case, we
might end up with something like this:
<div class="wb-empty" lang="arc" dir="rtl">No label defined</div>
That's obviously wrong, and I'd like to fix it.
== Fixing it ==
For fixing this, I tried to make MessageCache provide the language a
message was taken from [1]. That's not too straight-forward to begin
with, but while working on it I realized that MessageCache is only
responsible for following the language fallback chain for database
translations. For file-based translations, the fallbacks are directly
merged in by LocalisationCache, so the information is not there anymore
at the time of translating a message. I see some ways to fix this:
* Don't merge messages in LocalisationCache, but perform the fallback on
request (possibly caching the result)
* Tag message strings in LocalisationCache with the language they are in
(sounds expensive to me)
* Tag message strings as being a fallback in LocalisationCache (that way
we could follow the fallback until we find a language in which the
message string is not tagged as being a fallback)
What do you think?
[1] https://gerrit.wikimedia.org/r/282133
Thanks,
--
Adrian Heine né Lang
SOFTWARE DEVELOPER
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30 219 158 26-0
http://wikimedia.de
Imagine a world, in which every single human being can freely share in
the sum of all
knowledge. That‘s our commitment.
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der
Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
The Wikimedia Language team has been assembling monthly reports about
language support activities for one year. You can read the latest
report at:
https://www.mediawiki.org/wiki/Wikimedia_Language_engineering/Reports/2016-…
Highlights for May include: Special:Translate got an edit summary
field and modernization of web font formats: woff2 is in, eot is out.
Due to the nature of our work, the Language team [1] (Amir, Kartik,
Pau, Runa, Santhosh, and myself) alone cannot adequately support all
the languages of the Wikimedia movement. That is why the report
includes work by volunteers. We have bolded the names who we believe
are contributing as volunteers.
This report focuses on technical activities. You wont find future
plans or high level roadmap items on it. There is currently a major
omission: the i18n work of MediaWiki core itself. That is lacking
because it is more difficult to filter those activities and also
because we have not had much time for MediaWiki core i18n work.
To acknowledge the work of volunteers and to support them better, the
Language team released a statement of intent for code review [2] about
six months ago. To summarize: we attempt to review patches not by us
within a week, and patches stalled due to no updates after review for
three months will be abandoned -- unless we feel they are worth fixing
ourselves.
When we released the statement, we also agreed to reduce the existing
backlog of open patches. The results so far are positive, even though
it is easy to find examples where we have not been able to follow our
intent. Translate extension had 35 open patches when we started in
February -- at end of May it had only 12 open patches [3]. Universal
Language Selector had gone from 10 to 6, and fewer of them unreviewed.
Content Translation had gone from 15 to zero. Our jquery repositories
in GitHub have not fared as well, but we hope to achieve similar
results there in the future.
We excluded many repositories from the statement of intent in the fear
that we would add too much of a burden to ourselves. To our delight,
except MediaWiki core i18n, all those repositories have had swift
reviews and I count only two open patches in them.
- Niklas (on behalf of the Language team)
[1] https://www.mediawiki.org/wiki/Wikimedia_Language_engineering
[2] https://www.mediawiki.org/wiki/Wikimedia_Language_engineering/Code_review_s…
[3] The numbers change constantly. As of 2016-06-17 Translate has 23
open patches, but only 10 of them not from our team. Universal
Language Selector has 13 patches, 5 of them not from our team. Content
Translation currently has 6, one of them not from our team.
[x-posted announcement]
Hello,
The next online office hour session of the Wikimedia Language team is
scheduled for next Wednesday, June 15th, 2016 at 13:00 UTC. This session is
going to be an online discussion over Google Hangouts/Youtube with a
simultaneous IRC conversation. Due to the limitation of Google Hangouts,
only a limited number of participation slots are available. Hence, do
please let us know (on the event page
<https://plus.google.com/u/0/events/cd1bfs8111cbd4lmegqthma65c8>) if you
would like to join in the Hangout. The IRC channel #wikimedia-office and
the Q&A channel for the youtube broadcast will be open for interactions
during the session.
Our last online round-table session was held in March 2016. You can watch
the recording here: https://www.youtube.com/watch?v=0FrowkpBEnQ
I would also like to mention that our team is currently inviting feedback
for Content Translation via a community consultation
<https://www.mediawiki.org/wiki/Content_translation/Community_Consultation_J…>
which will conclude on June 22nd, 2016. We will make a note of any related
feedback received during this session and review it along with the other
comments received on-wiki.
Please read below for the event details, including local time and do let us
know if you have any questions.
Thank you
Runa
== Details ==
# Event: Wikimedia Language team's office hour session
# When: June 15, 2016 (Wednesday) at 13:00 UTC (check local time
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160615T1300)
# Where: https://plus.google.com/u/0/events/cd1bfs8111cbd4lmegqthma65c8 and
on IRC #wikimedia-office (Freenode)
# Agenda:
- Updates from the Language team and Q & A.
- Content Translation community consultation:
https://www.mediawiki.org/wiki/Content_translation/Community_Consultation_J…
--
Language Engineering Manager
Outreach and QA Coordinator
Wikimedia Foundation