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
I writing to you by recoomendation of Andre Klapper
<https://www.mediawiki.org/wiki/User:AKlapper_(WMF)> about the issue, and
he said that I should ask The Language Engineering team about the issue I
wrote about.
I am writing as a bureaucrat of mk.wiki on the suggestion of other active
editors and admins who feel that there is one issue that needs addressing
on our wiki.
Namely, that is the italics, whenever we use them. Unicode automatically
shows the East Slavic italics, where several letters are different than in
our own (and Serbian) alphabet. See the heading Differences from other
Cyrillic alphabets
<https://en.wikipedia.org/wiki/Serbian_Cyrillic_alphabet#Differences_from_ot…>
in
the Serbian alphabet article (the image to the right shows the
differences.. The correct ones for Macedonian and Serbian are i in the
rightmost, yellow column). Same applies to Macedonian, i.e. it is the same
letters that are different. In the text further near the end of the
section, it mentions OpenType and things I don't udnerstand.
Our question, as a wiki-community is: is it possible to have something done
on our wiki (something to be installed) or elsewhere, so that we will get
the proper letters? I know that some free fonts support this, but I am not
sure which. I am sure the Serbians will also be interested to implement
this on their wiki (although their case is somewhat more complicated by the
fact they use dual script on all pages).
We, as a community, use different operating systems and browsers, but
everyone sees the Russian-Bulgarian italics, not the Macedonian/Serbian
ones.
Below I have a screenshot of a test I just made for each of the letters.
Here is again the table of differences
<https://commons.wikimedia.org/wiki/File:Serbian_Cyrillic_Italic.svg>. The
ones we want are in the rightmost (yellow) column. We are asking if it is
possible for all italics to be displayed this way on the wiki. This will
need some special intervention (I assume) as currently we don't have them,
but the Russo-Bulgarian in stead. (See screenshot below)
This applies to every OS and browser, because it is a standard by Unicode
that hasn't been modified yet to introduce our letters, and so it is, by
definition, impossible for us to get Maced./Serb. italics without tweaks in
the wiki. Our question is: are those tweaks possible, so our italics will
look like that in the yellow column.
I hope there may be a solution for our community.
Thank you very much,
Bojan Jankuoski,
User: User Bjankuloski06 / Б. Јанкулоски
<https://mk.wikipedia.org/wiki/%D0%9A%D0%BE%D1%80%D0%B8%D1%81%D0%BD%D0%B8%D0…>
--
Бојан Јанкулоски I Bojan Jankuloski
Главен програмски раководител I Chief Program Manager
Споделено знаење I Shared Knowlege
тел. | tel. +38978 282 698
Hello all,
I would like to announce the release of MediaWiki Language Extension
Bundle 2016.01. This bundle is compatible with MediaWiki 1.25.x and
1.26.x.
Next MLEB is expected to be released in 3 months. If there are major
changes or important bug fixes, we will do intermediate release.
Please give us your feedback at
[[Talk:MLEB|https://www.mediawiki.org/wiki/Talk:MLEB]].
* Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2016.01.tar…
* sha256sum: 7a46bb96f852aa42f728c68e4e21558878c8cba703ce9f8f6c2316af7bbe03e3
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://phabricator.wikimedia.org/
* Talk with us at: #mediawiki-i18n @ Freenode
Release notes for each extension are below.
-- Kartik Mistry
== Babel, CleanChanges and LocalisationUpdate ==
* Localisation updates only.
== CLDR ==
* Hebrew names for Cebuano and Norwegian are fixed.
* cldr converted to extension registration. Please update your
LocalSettings.php!
== Translate ==
* Old custom tokens were deprecated in favor of using regular "csrf"
(previously known as "edit") token. If you are using Translate WebAPIs
you might need to migrate.
* Special:Translations no longer shows PHP notices for pages with
invalid language codes
* Special:Translate now longer shows deprecation warnings about access
keys in the JavaScript console.
* Translate is now syntactically compatible with PHP7.
* Message group selector on Special:SearchTranslations no longer has
glitchy behavior after selecting a group.
* MessageIndex code was optimized. It now ignored messages not in
$wgTranslateMessageNamespaces. By default this should be fine, but if
you have translations in custom namespaces, check that they are
included.
* Pages with <languages /> now load faster with cold caches.
* MachineTranslationAid no longer throws uncaught exceptions with
default configuration that broke other translation aids.
== UniversalLanguageSelector ==
* ULS now uses extension registration and thus requires MediaWiki 1.25 or later
* Input methods should now work inside Visual Editor.
* Fonts:
** OpenDyslexic font updated to latest upstream.
** Akkadian font should work again.
* Input Methods:
* New input methods:
** Rodali (Assamese) layout.
** OdiScript (Oriya) layout.
** Yoruba layout.
* Updated input methods:
** Updated Oriya Lekhani layout.
** Digit fixes in Southern Kurdish layout.
** Minor fixes in Sinhala layout.
--
Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_
{kartikm, 0x1f1f}.wordpress.com
I've expanded https://phabricator.wikimedia.org/T66430 .
We need more examples from languages where things can get problematic.
You are probably interested in this if you ever saw a mention of "pretty
timestamps", "human timestamps" or one of the following messages:
> "just-now": "just now",
> "hours-ago": "$1 {{PLURAL:$1|hour|hours}} ago",
> "minutes-ago": "$1 {{PLURAL:$1|minute|minutes}} ago",
> "seconds-ago": "$1 {{PLURAL:$1|second|seconds}} ago",
> "monday-at": "Monday at $1",
> "tuesday-at": "Tuesday at $1",
> "wednesday-at": "Wednesday at $1",
> "thursday-at": "Thursday at $1",
> "friday-at": "Friday at $1",
> "saturday-at": "Saturday at $1",
> "sunday-at": "Sunday at $1",
> "today-at": "$1",
> "yesterday-at": "Yesterday at $1",
Nemo
An i18n upgrade project started in 2011 finally completed, thanks to
many Google code-in students, Florian, Reedy and others.
Propose your tasks for GCI students too. :-)
https://www.mediawiki.org/wiki/Google_Code-in_2015
Nemo
---------- Forwarded message ----------
From: *Florian Schmidt*
Date: Tuesday, January 5, 2016
Subject: [Wikitech-l] [INFO] wfMsg*() was removed
Hello readers of this list :)
tl;dr
MediaWiki's wfMsg*() functions were removed in MediaWiki 1.27.
Long version:
Maybe someone has already seen the work on the wfMsg*() deprecation task:
https://phabricator.wikimedia.org/T70750
<https://phabricator.wikimedia.org/T70750>
A little bit of background:
MediaWiki provides different functions to get a localised message string,
the one you normally choose is wfMessage, which creates a Message object.
However, there are other global functions (including wfMsg(),
wfMsgForContent(), wfMsgHtml() and so on), too, which was deprecated in
MediaWiki 1.18 (with deprecating notification in 1.21) in favour of
wfMessage. Unfortunately, a lot of (maybe unmaintained) extensions still
used the old deprecated functions to get a localised message.
After a huge amount of changes to these extensions (tracked in the linked
task), we now hope, that all usages of these functions are replaced by it's
modern wfMessage-counterpart, at least we did our best to find affected
extensions :)
Now, the time has come, that the change to mediawiki/core, which removes
the old deprecated functions[1], was merged. This notification is mostly
for people, who still use these functions, if you're sure you don't, you
can stop reading here :P
If you're a maintainer of an extension, please make sure, that you don't
use these wfMsg*() functions anymore (if your extension is hosted in
Wikimedia Gerrit, you probably mentioned a change named "Remove wfMsg*
calls", so we already did the work for you. If not, please take some
minutes to find out, how you can migrate to the new wfMessage function to
keep compatibility with newer MediaWiki releases. If you want to replace
your usage of wfMsg* functions your best friend (mostly) is the
documentation page[2], which describes appropriate replacements with the
actual message functions. However, it's possible, that your case of usage
isn't mentioned there, and if so, you could first try to find a better
approach using the Message object (returned by wfMessage()), which is
documented on doc.wikimedia.org <http://doc.wikimedia.org>
<http://doc.wikimedia.org> [3], or, if you
really don't know, what to do, ask in #wikimedia-dev or on this mailing
list :) I think you'll get help as soon as possible.
I hope this answers all questions, if not, feel free to answer this e-mail
:)
Best,
Florian
[1] https://gerrit.wikimedia.org/r/#/c/262333
<https://gerrit.wikimedia.org/r/#/c/262333>
[2] https://www.mediawiki.org/wiki/Manual:Messages_API#Help_
with_replacing_deprecated_wfMsg.2A_functions
<https://www.mediawiki.org/wiki/Manual:Messages_API#Help_with_replacing_depr…>
[3] https://doc.wikimedia.org/mediawiki-core/master/php/
html/classMessage.html#
<https://doc.wikimedia.org/mediawiki-core/master/php/html/classMessage.html>
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org <javascript:;>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
