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.
Hi,
We, the i18n team, are working on automated test cases for the plural
forms for languages and we found support for fractional numbers is
incomplete.
Some languages have a separate plural form if the number is a fraction number.
For example, Russian language, according to CLDR[1] has 4 plural
forms. They are:
'one' for 1, 21, 31, 41, 51, 61...
'few' for 2-4, 22-24, 32-34...
'many' for 0, 5-20, 25-30, 35-40...
'other' for 1.2, 2.07, 5.94...
Note the 'other' form, it is for fractional numbers. This bug:
https://bugzilla.wikimedia.org/show_bug.cgi?id=28128 also lists a
Polish language example. In the above Russian rules, Mediawiki as of
now defines only 3 forms. So that is a bug as reported in Bug 28128.
If you can check the plural form definition for your language in CLDR
using http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/language_plural_r…
and check if Mediawiki implementation is correct for your language,
it will be a great help to us.
CLDR plural forms may not be 100% correct, but there are ways to
correct it. Mediawiki plural rules often fallback to the last form
supplied using {{PLURAL...}} syntax, but that is not well tested. You
can test the behavior of plural in your language by trying a test page
with content like
{{PLURAL:10.5|plural-form-1|plural-form-2|plural-form-n}} in your
wiki. If you give correct number of forms as per your language, and if
not getting the correct form with fraction numbers, let us know by
reporting a bug in Mediawiki bugzilla[2].
[1] http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/language_plural_r…
[2] https://bugzilla.wikimedia.org/
Thanks
Santhosh Thottingal
Hoi,
At the moment we are reaching out to all the language communities that have
a Wikipedia. For some languages we have had reasons to reach out earlier;
they are the language communites of Indian languages and the language
communities where we identified issues with our MediaWiki plural
definitions.
As a result of the outreach about plural support, we are now looking into
the plural rules for Scots Gaelic. As you can read in the translatewiki
thread, these rules are used in several applications and it is beneficial
when the applicable standard has correct information about this so that it
is easy to implement. It is really heartening to learn that bugs have been
posted at the CLDR to include this language.
http://translatewiki.net/wiki/Thread:Support/New_plural_rules_for_Scots_Gae…
As support for things like plural are often implemented when a large body
of code has already been written, it follows that the existing code needs
to be refactored to include support for plural, grammar, gender in
messages. In many threads in Support at translatewiki.net, you will find
people indicating single messages. These are often readily picked up by the
staff at translatewiki.net. However, there are big projects that linger on
to mind comes logging. The log files are often about people, they do have a
gender and consequently many of the messages need change and support
gender. The good news is that Niklas build the framework that allows for
gender support in log messages. The bad news is that it is a big job that
needs doing for many logs.
If you are interested in working on the MediaWiki code and improve its
language support, we are quite happy to point you to what needs doing and
we do lend a hand when need be.
Thanks,
Gerard
Please find the report on the latest[1] i18n triage below. The rough
notes are on etherpad:
http://etherpad.wikimedia.org/BugTriage-i18n-2012-01.
Thanks go to the participants liangent, Nemo_bis, srikanthlogic,
OrenBo, ^demon, aharoni, Nikerabbit, santhosh and hexmode.
We covered three main topics: WebFonts, Narayam and Translate.
WebFonts
--------------
Support WebFonts for Chinese -- This topic does not yet have a
bugzilla entry. Because of the complexity, it was agreed that Liangent
and Santhosh would discuss firther. Availability of fonts for Chinese
and their potential large size is an issue. This will require some
more discussion to understand the issue more clearly and to think
about solutions -- there are more than 47.000 characters involved.
Liangent suggested Font Subsetting -- creating downloadable fonts
tailored for a pageon the fly -- but there are multiple issues with
that.
Narayam input methods
--------------------------------
https://bugzilla.wikimedia.org/31904 -- Bamini keyboard map needs fix:
We are looking for a community member to validate the mapping.
srikanthlogic volunteered to track somebody down.
https://bugzilla.wikimedia.org/32029 -- Some vowel combination in
Sinhala Wijesekara need to be corrected: We are looking for a
community member to validate the mapping.
https://bugzilla.wikimedia.org/33243 -- Narayam IME on fails to
replace English characters on mobile: This report contains at least
two separate issues. For tracking purposes, that's not great; one
should be split off. Because of the multitude of mobile and tablet
devices, each with their own resolution, screen dimension and aspect
ratio, something like "Narayam on mobile" will probably not be a one
size fits all solution, like it is implemented on desktop browsers.
Siebrand will open a discussion with the mobile team on what we think
we can do with input methods on mobile devices.
https://bugzilla.wikimedia.org/33300 -- Unwanted activation which
disables user's ability to type: It's unclear how to proceed with
this. We are thinking about something visual in the proximity of the
text area or input field. This needs to be discussed with UI/UX
people. Siebrand will follow up, and UI/UX designers have been CC-ed
on the issue, but have not yet added their thoughts.
https://bugzilla.wikimedia.org/33480 -- Add Telugu Transliteration
input method to Narayam: A Telugu community member/developers is
needed to port the existing input method gadget to Narayam. Hexmode
will chase down a tewiki user/dev.
Script to automate transliteration help maps -- This topic does not
yet have a bugzilla entry. srikanthlogic suggested this for
transliteration tables liike
http://www.mediawiki.org/wiki/Help:Extension:Narayam/Tamil/Transliteration.
Opinions differ on if this would contribute anything valuable, as
each transliteration schema is different, and these tables may always
need to be created manually. Siebrand to schedule a session to discuss
this further.
Translate
------------
https://bugzilla.wikimedia.org/31632 -- When re-marking translatable
page for translation, old version of the pages might be shown: It
looks like this behaviour is no longer observed. The issue was closed.
https://bugzilla.wikimedia.org/31695 -- Support Google Translate V2
API: Google has deprecated and limited use of the Translate V1 API.
We're looking for a volunteer to update the interface, but one has not
been found yet.
https://bugzilla.wikimedia.org/32983 -- Page protection leads to issue
in translatable pages: It looks like Translate may be missing a hook
or it might be using the wrong hook. We're planning on asking Roan for
help.
https://bugzilla.wikimedia.org/33647 -- Translate popups with
insufficient height: This appears to be an intermittent, but annoying
issue. During the triage no additional understanding has arisen.
Anyone with information that may reliably reproduce this issue is
requested to please add steps and details in bugzilla.
Cheers! In February, there will be another Localisation and
internationalisation bug triage.
[1] http://lists.wikimedia.org/pipermail/mediawiki-i18n/2012-January/000383.html
--
Siebrand Mazeland
Product Manager Localisation
Wikimedia Foundation
M: +31 6 50 69 1239
Skype: siebrand
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
On Fri, Jan 13, 2012 at 21:12, Mahitgar from Marathi Wikipedia <
mahitgar(a)yahoo.co.in> wrote:
> Hi,
> Sorry if I am putting my request at wrong place ,Please forward the same
to
> right people if you happen to know them on my behalf .I here with
earnestly
> request to make mailman wikimedia mailing list/mailman localisation
> translation facility avaialable at translatewiki.net
>
> While currently location based one or two mailing lists are available but
> most of Marathi language wikipedians prefer to receive mailing list
messages
> and mailing list moderation in Marathi language.So we will be start using
> wikimedia mailing list only after localisation for marathi wikipedians.
>
> .Presently we are convincing diverting and training lot of wikipedians
from
> our wikipedia to work on translation of media wiki and mediawiki
> translations.One is our available pool of editors is already small and
many
> people from translation background find it difficult to cope up with
> different different environments.
>
> thank you and warm regards
>
> mahitgar from Marathi wikipedia
See http://wiki.list.org/display/DEV/Internationalization (kinda recent)
and http://wiki.list.org/display/DEV/Managing+Translations (ancient)
-Jeremy
Hoi,
In the last month, this list has gained many new subscribers; they are
people who are members of a language support team. As you may understand,
the Wikimedia Localisation team is not able to understand all the
intricacies of the 280+ languages we support at the Wikimedia Foundation.
It is for this reason that we need help and the best way is when people who
are knowledgeable enough provide us with their knowledge.
Recently we have added support for grammatical gender and plural for
JavaScript. As you may know, we already supported gender and plural in PHP
for quite some time. As part of the process Santhosh made an inventory of
the differences between the implementation in MediaWiki and in the standard
for such things, the CLDR. I blogged about the result on the Wikimedia
Foundation blog.
As I also reached out to the Wikipedias of the language that have an issue,
we gained both more people who are interested to provide support for their
language but as relevant, we learned that entering data in the CLDR is
overly complicated. Even our developers, who are also linguists or language
experts have a hard time entering the data for plural support.
Even when there is no information in the CLDR about things like plural
support, we want to support this in MediaWiki. When the information we get
about the rules for plural support are given to us with references either
on the Internet or in publications, it is relatively straightforward to
create a bug report to the CLDR. What we are looking for are people who can
help us with getting the necessary information so that we can implement it
in MediaWiki, have it tested by a language community and then post a bug
report at the CLDR. If need be, our developers can help with the
formulation of plural rules in the format of the CLDR
Another really interesting development was for the Arabic script. We
learned about the Amiri font, a font that supports all the characters of
the Arabic script and consequently is able to support not only Arabic but
also languages like Urdu, Kashmiri etc. We wrote to the developer of the
script and he was happy for us to use his font in a WebFonts implementation.
Not so funny is that we learned that the support of the Arabic script in
MediaWiki is problematic. It turns out that we do not fully comply with the
rules for merging parts of a character (including diacritics). This is not
only an issue for MediaWiki but also for some of the modern browsers. We
will be talking about how MediaWiki is to be fixed with Brion Vibber at the
upcoming FOSDEM conference in Brussels and we have posted bugs for the
browsers.
At some stage we will have fixed MediaWiki and at that time we will need
people to test their language and see if everything looks as you expect it.
When your language has problems with fonts or input methods, we are quite
happy to support your language as well. For WebFonts we need a freely
licensed font that can be used on all the major operating systems and
preferably on the versions that are still in use (several versions of IE
are technically unable to support WebFonts at all). For input methods we
need a mapping from the international keyboard to the keyboard as expected.
This includes information on the rules of how characters are to be combined.
As a member of a language support team you are VERY welcome to come forward
with requests for the support of fonts or input methods. We do expect your
involvement with both the implementation and the testing. We are also very
appreciative when you communicate this widely in your language community.
As always we can test these things at translatewiki.net. This is where we
run the latest MediaWiki software before it goes into production on any of
the Wikimedia Foundation's projects.
Thanks,
Gerard
http://blog.wikimedia.org/2012/01/13/addressing-the-many/http://ultimategerardm.blogspot.com/2012/01/supporting-font-for-arabic.htmlhttp://translatewiki.net/wiki/Language_support_team
