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,
I'd like to start a discussion about the merits and challenges of
> enabling the Translate and UniversalLanguageSelector extensions on
> Commons.
>
> The UniversalLanguageSelector extension (
> https://www.mediawiki.org/wiki/Extension:UniversalLanguageSelector )
> allows users to easily switch the interface language; it also embeds
> an interface to enter text in non-Latin languages even if your
> keyboard doesn't allow it.
>
> My feeling is that both these tools would dramatically improve the
> user experience on Commons for people who don't use English. As a
> multilingual wiki, Commons even seems like the perfect audience for
> these tools.
>
FYI, I quick drafted
<
https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/UniversalLa…
>
in order to discuss the possible issues, then gain community consensus and
hopefully get ULS enabled on Wikimedia Commons
(I thought it was better to leave the question of the Translate extension
to another discussion, as there seems to be more hurdles with the
transition).
Thanks,
--
Jean-Frédéric
Reza,
+mediawiki-i18n mailing list.
I checked few of the languages and I believe most of them in the drop-down
list are available in CLDR 22.1 are already present in that list with
proper translations. Apparently, there is another issue with inheritance in
their use of CLDR. For example in that language drop-down in the page you
mentioned, "ug" (Uyghur) is properly translated as "اویغوری", but the
following choices "ug-arab" and "ug-latn" which specify if the language is
written in Arabic or Latin script, are not. In this case the parent locale
("ug") shouldn't be displayed at all (hence http://goo.gl/Koy3x) and the
name of the language and appropriate scripts (which exists in CLDR as well)
should be used for the script variants of the locale ("ug-arab" and
"ug-latn"). It might be an issue which raise when the translated script
name is missing in CLDR data since the label for "ku-arab" is displayed
okay.
More major problem here is that lots of these languages are not - yet -
supported by CLDR. The following link shows a list of languages which are
added to CLDR as supported languages for content submission (locale data,
etc.):
http://st.unicode.org:8080/cldr-apps/survey?_=root&x=Languages
And here are the Persian translations:
http://st.unicode.org:8080/cldr-apps/survey?_=fa&x=Languages
Wikimedia projects support way more languages (specifically minority ones)
and it's desired to add the locale data for these to CLDR, but the process
is not very straightforward for common users of Wikimedia projects. There
were some efforts to assist users of various Wikimedia projects to submit
data to CLDR (see
http://translatewiki.net/wiki/Language_support_team/CLDR-2012).
All in all, I'm interested in a relatively more straightforward solution to
collect some of the locale data from the Wikimedia projects community to be
submitted to CLDR.
Regards,
Shervin
↪ http://about.me/shervinafshar
On Fri, Mar 1, 2013 at 10:20 AM, reza moshksar <reza.moshksar(a)gmail.com>wrote:
> Hi,
> I want to localize https://www.mediawiki.org/wiki/Extension:CLDR and it
> uses CLDR data.
> i.e. if you check here<http://translatewiki.net/w/i.php?title=Special:Translate&group=mediawiki&la…> by
> clicking on زبان tab it shows each language but some of them are not
> translated to Farsi .
>
> Does any one know where can I translate these language names? I am
> confused.
>
> --
> --
> REZA MOSHKSAR
> Phd of Architecture in Building, Environment, Science and Technology
> B.E.S.T Department - Politecnico di Milano
> Via Bonardi 9 20133 Milano Italy
>
> --
> --
> http://persian-computing.org/
> http://groups.google.com/group/persian-computing/
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Persian Computing" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to persian-computing+unsubscribe(a)googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
Hallo,
I would like to announce the release of MediaWiki language extension
bundle 2013.04
* https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2013.04.tar…
* sha256sum: bd6aca60101308f429d90d421e35093328e7a05ea74d35c05a98474ab648dec4
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.
Amir E. Aharoni
== Babel ==
Only localisation updates.
== cldr ==
* Update CLDR to 23 and rewrite parser
== CleanChanges ==
No changes.
== LocalisationUpdate ==
No changes.
== Translate ==
=== Highlights ===
Work continued on stabilizing the new Translate UX (TUX) interface.
Specifically, numerous fixes were made to make TUX work correctly in
Microsoft Internet Explorer.
The "message tools menu" was added to give easy access from the
message translation interface to the history of the message and to
translations in all languages (Special:Translations).
Basic file format support was added for Xliff.
Initial work was done to add support for sandboxing - allowing users
to make several test translations before getting full translation
permissions. This is an incomplete experimental feature and it is not
active by default.
=== Noteworthy changes ===
* Removed the hide tab that appeared even though there were no more warnings.
* Messages saying that there is nothing to proofread were clarified.
* Show "Cancel" instead of "Skip" at the last message in the curent view.
* Clicking a suggestion copies the suggestion to the translation field
(previously, a user had to press a link, which was harder).
* Simple paging for translation search results.
* <tvar|> no longer visible on translation pages in source language (bug 46925)
* The bottom toolbar is always shown, even without a scroll.
* When a user modifies a translation, it is no longer proofreadable (bug 46687)
* Numerous minor styling changes.
* RTL fixes for Special:Magic, to ensure cleaner display of magic words
in right-to-left translations.
== UniversalLanguageSelector ==
=== Highlights ===
Starting with this release, MLEB is no longer compatible with
MediaWiki 1.19. To use MLEB 2013.04 or later, you must used it
combined with MediWiki 1.20.4 or a later version.
Work began on making the ULS appear in the sidebar rather than at the
top of the page near the personal links menu. This is an incomplete
and experimental feature. It can be tested by setting the variable
$wgULSPosition to 'interlanguage'.
=== Noteworthy changes ===
* Wikimedia Foundation's GeoIP service is now used by default for
detecting the user's location and guessing the suggested language.
* A web font for the Divehi language was added.
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
The next i18n deployment window is on Tuesday 2013-04-30 starting at 08:00 UTC.
For bug 46716 [1] we will run a script refresh-translatable-pages.php
for all wikis using the Translate extension. It will ensure that all
translation pages will be up to date. As a side effect, it will also
remove any fuzzy/outdated translations still left in translation pages
(many of those have already been removed due to updates triggered by
translation edits).
Potential real fix for bug 46716, will get deployed along with
1.22wmf3 [2] as well as the fix for bug 47178 [3]. This bug caused a
lot of unnecessary invalidation of translations, contributing to the
many complaints about the new way of handling outdated translations.
See [4].
[1] https://bugzilla.wikimedia.org/46716
[2] https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap#Schedule_for_the_depl…
[3] https://bugzilla.wikimedia.org/47178
[4] https://bugzilla.wikimedia.org/44328
Hello,
I have drafted a proposal for my GSoC Project: jQuery.IME extensions for
Firefox and Chrome. I would love to hear what you think about it.
I would really appreciate any kind of feedback and suggestions. Please let
me know if I can improve it in any way.
My proposal can be found here:
http://www.mediawiki.org/wiki/User:Prageck/GSoC_2013_Application
Thanks,
Praveen Singh
Hi
I am Harsh kothari I am an engineering student at L.D college. I have been
an open source contributor since last 2 years and am contributing in
MediaWiki since last 8 months. I am passionate about coding and enjoy it
too. I also have been participating in various open source events in
Gujarat as well outside of it.
I am submitting a proposal on Language Coverage Matrix dashboard as my GSoC
2013 project. It would help automate the information about language support
provided by the Language Engineering team for e.g. key maps, web fonts,
translation, language selector, i18n support for gender, plurals, grammar
rules. The LCM would display this information as well as provide
visualization graphs of language coverage using various search criteria
such as tools or languages. it will be of tremendous use to the Language
Engineering Team.
The below mentioned link will elaborate more on my proposal.
http://www.mediawiki.org/wiki/User:Harsh4101991/GSoC_2013
Bug filed on Bugzilla
https://bugzilla.wikimedia.org/show_bug.cgi?id=46651
Looking forward to suggestions and inputs.
Thanks
Harsh
--
Harsh Kothari
Engineering Trainee,
Physical Research Laboratory.
Follow Me : harshkothari410 <https://twitter.com/harshkothari410/>
Hello,
The notes from the monthly bug triage session hosted by the Language
Engineering team on 24th April, 2013 can be found at:
https://www.mediawiki.org/wiki/Language_Testing_Plan/Triage20130424
This and notes from all the earlier triage sessions can now be seen
from the Language Testing page[1]. This list includes the open
sessions as well as the triage sessions that the language engineers
have from time to time. We'll be posting notes from our upcoming
sessions in future also in this section.
Thanks
Runa
[1] https://www.mediawiki.org/wiki/Language_Testing_Plan#Bug_Triage
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
>
> Also, did you think of the accessibility issues in your solution?
First, I want to clarify that the prototype was made just to communicate
the idea in terms of interaction. The The implementation is just a quick
hack to simulate this interaction.
For a production implementation I can image the whole list of languages to
be sent to the client, and then, the list being shortened by Javascript.
For those users without Javascript (from screen-readers, to Search engine
crawlers) the same list of links they receive now will be available for
them.
In any case, developers could provide even better strategies to solve that.
As an interaction designer I just wanted to share the idea to collect
possible concerns with the interaction proposed, to be fixed in next
iterations of the designs before development effort is made.
On Sat, Apr 20, 2013 at 2:04 AM, Mathieu Stumpf <
psychoslave(a)culture-libre.org> wrote:
> Also, did you think of the accessibility issues in your solution? Here I
> especialy think of people with view disabilities, for who js often mean
> no way to get the content, while a long list of hyperlinks is
> manageable.
>
> Le vendredi 19 avril 2013 à 20:19 +0200, Pau Giner a écrit :
> > Thanks for all the feedback!
> >
> >
> > I'll try to respond below to some of the issues raised:
> >
> >
> > Which is the problem?
> >
> >
> > As it has been mentioned, one of the most effective ways of hiding
> > something is to surround it in the middle of a long list. This
> > produces two problems:
> > * Lack of discoverability. users may be not aware that the
> > content is available in their language (which goes against our
> > goal of providing access to knowledge). Speakers of small
> > languages that access the English Wikipedia because it has
> > more content, are forced to make an effort each time to check
> > if each article is also available in their language.
> > * Problems for multi-lingual exploration. It is hard to switch
> > between multiple language versions since the users has to look
> > for his languages each time in the whole list.
> >
> >
> > The fact that some Wikipedias adjust the order of the languages, the
> > existence of user scripts and an Opera extension to solve the issue,
> > is an indicator of the existence of such problem.
> >
> >
> >
> > We support lots of languages (+300) but users are normally interested
> > in a small (1-8) subset of those. We need to make these subset easily
> > discoverable for our users, and providing them in the middle of a list
> > with 200 items is not the best way to do it in my opinion.
> >
> >
> > Possible cultural and value problems
> >
> >
> > As it was commented, the multilingual nature of Wikipedia is a strong
> > held value. However, currently it is hard to know in how many
> > languages an article is available since you need to count the links.
> > With the proposed approach we provide a number which helps to
> > communicate that. So I think we are not going against that value.
> >
> >
> > I think that concerns about the imposition of languages per region are
> > not a big issue when the previous user choices and the browser accept
> > language are considered with more priority than Geo-IP. Users just
> > need to select their language once and it will be appearing in the
> > short list the next times. These concerns should be more relevant with
> > the current situation where some Wikis put some languages on top
> > regardless user choices (for some work 100% of the time, for others
> > they fail 100% of the time).
> >
> >
> >
> > I also don't think that we should prioritise the need to hide
> > "languages that users somehow dislikes" over making it easy to access
> > the languages that the user wants. In any case, the former is also not
> > supported with the current approach.
> >
> >
> > Why to hide?
> >
> >
> > I understand the problems commented when language links were initially
> > hidden in Vector, since uses were required to make an additional step
> > to get into the same long list of links we currently have. With the
> > proposed approach, the extra step is only taken in exceptional cases
> > (e.g., a user in a foreign country accessing from a public pc), and
> > this is made only once (not for each language change), and aids such
> > as search are provided to make it really quick.
> >
> >
> > The reordering alternative has some problems compared with the
> > proposed approach. For example, when a language does not appear on
> > top, it is hard to determine whether the current article is not
> > provided in that language or it is in the middle of the list. In
> > addition, with reordering, you cannot rely on alphabetical order
> > (while you can present the short list alphabetically).
> >
> >
> >
> >
> > Considering size and quality of the article
> >
> >
> > It can be a factor to consider since communicating that an article has
> > good versions in other languages is a good thing. But I think it is a
> > low priority one, since I find hard to imagine a user selecting a
> > language which she does not understand (otherwise will be already in
> > the short list) just because the article is of good quality. In any
> > case, users normally speak 1-8 languages, so even in a relatively
> > short list there is still room for other criteria.
> >
> >
> > The way to access more
> >
> >
> > We choose the "..." so that the label could work across languages. So
> > that you can go back to your language if you arrive by accident to a
> > foreign Wikipedia (or you are an advanced user curious to check if web
> > fonts were enabled in Javanese wikipedia). However, the visual
> > execution needs some work still to make it more touch friendly among
> > other things.
> >
> >
> > Details on the language list UI
> >
> >
> > The interactive prototype was created to communicate the main idea and
> > most details are still lacking.
> >
> >
> > Thanks for pointing layout and navigation problems. The layout of the
> > list is one of the aspects that needs more work: currently we group
> > the languages by script to help the user to recognise their familiar
> > scripts, and the algorithm also makes some control of orphan/widow
> > items. That works well for very long lists of languages, but needs
> > further tuning when the number of elements is reduced. An algorithm
> > that presents the list optimally for all possible lengths is something
> > to be done.
> >
> >
> >
> >
> >
> >
> > Pau
> >
> >
> > --
> > Pau Giner
> > Interaction Designer
> > Wikimedia Foundation
> >
> >
> > On Thu, Apr 18, 2013 at 6:50 PM, Pau Giner <pginer(a)wikimedia.org>
> > wrote:
> > 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 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),
> > 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
> >
> >
> >
> >
> > --
> > Pau Giner
> > Interaction Designer
> > Wikimedia Foundation
> > _______________________________________________
> > Design mailing list
> > Design(a)lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/design
>
>
> _______________________________________________
> Design mailing list
> Design(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/design
>
--
Pau Giner
Interaction Designer
Wikimedia Foundation
Hello,
This is a reminder that the Language Engineering team will be hosting
a bug triage session today, i.e. 24th of April 2013 at 1700 UTC/1000
PDT on #mediawiki-i18n (Freenode). The bug list is at
http://etherpad.wikimedia.org/BugTriage-i18n-2013-04 . Event details
can be found be in the section below.
Thanks
Runa
What: Translation User Interface bug triage
Date: April 24 2013
Time: 1700-1800 UTC, 1000-1100 PDT (Timezone conversion: http://hexm.de/r0)
Channel: #mediawiki-i18n (Freenode)
Etherpad: http://etherpad.wikimedia.org/BugTriage-i18n-2013-04
Questions can be sent to: runa at wikimedia dot org
---------- Forwarded message ----------
From: Runa Bhattacharjee <rbhattacharjee(a)wikimedia.org>
Date: Sat, Apr 20, 2013 at 1:02 AM
Subject: [Language Engineering] Bug triage on Wednesday, April 24 2013
at 1700 UTC/1000 PDT
To: mediawiki-i18n(a)lists.wikimedia.org, Wikimedia Mailing List
<wikimedia-l(a)lists.wikimedia.org>, wikitech-l(a)lists.wikimedia.org
What: Translation User Interface bug triage
Date: April 24 2013
Time: 1700-1800 UTC, 1000-1100 PDT (Timezone conversion: http://hexm.de/r0)
Channel: #mediawiki-i18n (Freenode)
Etherpad: http://etherpad.wikimedia.org/BugTriage-i18n-2013-04
Questions can be sent to: runa at wikimedia dot org
Hello,
The Language Engineering team would like to invite everyone for the
upcoming bug triage session on Wednesday, April 24 2013 at 1700 UTC
(1000 PDT). During this 1 hour session we will be using the etherpad
listed above to collaborate. We have already listed some bugs, but
please feel free to add more bugs, comments and any other related
issues that you’d like to see addressed during the session. You can
send questions directly to me on email or IRC (nick: arrbee). Please
see above for event details.
Thank you.
regards
Runa
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
What: Translation User Interface bug triage
Date: April 24 2013
Time: 1700-1800 UTC, 1000-1100 PDT (Timezone conversion: http://hexm.de/r0)
Channel: #mediawiki-i18n (Freenode)
Etherpad: http://etherpad.wikimedia.org/BugTriage-i18n-2013-04
Questions can be sent to: runa at wikimedia dot org
Hello,
The Language Engineering team would like to invite everyone for the
upcoming bug triage session on Wednesday, April 24 2013 at 1700 UTC
(1000 PDT). During this 1 hour session we will be using the etherpad
listed above to collaborate. We have already listed some bugs, but
please feel free to add more bugs, comments and any other related
issues that you’d like to see addressed during the session. You can
send questions directly to me on email or IRC (nick: arrbee). Please
see above for event details.
Thank you.
regards
Runa
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
Hello,
The Wikimedia Language Engineering team announced the launch of the
the pilot phase of the Language Maven outreach program during their
recent IRC office hour[1]. To kick-off the program, the team hosted an
online meeting with some of the Language Mavens where matters related
to the scope of the project were discussed. It was also proposed to
prepare checklists of the available tools and other related items that
can be used by the Mavens as ready-reckoners. Another meeting has been
set to be held during the month of May to be followed thereafter by
regular monthly meetings. The program has met with a positive response
and is expected to bridge the gaps that currently exist between the
Wikimedia projects in different languages. The summary of the
discussions can be found in the meeting notes[2]. Further discussions
will continue on the mediawiki-i18n mailing list.
We would also like to invite more participants into the program.
Please sign up by using the form located at the following link:
http://hexm.de/LangMavenSignUpForm
More details about the program can be found in the mediawiki page[3]
and questions can also be sent to the mailing list or directly to me
at: runa at wikimedia dot org
regards
Runa
[1] http://meta.wikimedia.org/wiki/IRC_office_hours/Office_hours_2013-04-10
[2] http://www.mediawiki.org/wiki/Language_tools/Language_Team_Plan/Language_Ma…
[3] http://www.mediawiki.org/wiki/Language_tools/Language_Team_Plan
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
Hoi,
I am the developer of the SignWriting MediaWiki Plugin. It enables a
SignWriting viewer for MediaWiki software. It supports an International
community and can be used for any sign language.
I just released a radically simplified version of the extension in
Gerrit: 20 lines of PHP code and 50 lines of Javascript.
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/SignWritingMed…
I am hoping someone can look over the code and point out any flaws.
I'm hoping it can be deployed on Incubator. I reopened a bug from long ago.
https://bugzilla.wikimedia.org/show_bug.cgi?id=22216
The PHP code makes a call to the Resource Module to load
"signwriting_thin.js" (3 KB file). The Javascript runs on the client
side only if Formal SignWriting is detected on the page.
There shouldn't be any security problems for the server running this
extension and there is a miniscule cost to the user's browser.
The MediaWiki extension is a wrapper for the SignWriting Thin Viewer
available on http://SignPuddle.com
Thanks for your consideration,
∼Steve
hi,
the freeplane project (http://freeplane.sourceforge.net) is currently
using mediawiki 1.14.1.
>From this page:
http://www.mediawiki.org/wiki/Extension:Translate
I derive that it's probably only supported in >= 1.19. Is this true?
What is the easiest way to make this (or a similar extension) work with
mediawiki 1.14.1 (of course while keeping the existing pages)?
Currently we have only English pages, but the Freeplane user base is
growing so we need French pages as well.
Thank you! Best Regards,
--
Felix Natter
<https://www.mediawiki.org/wiki/Localisation#Update_of_localisation>
will not be true for a short while.
Nemo
-------- Messaggio originale --------
Oggetto: [Wikitech-ambassadors] Temporarily disabling l10n update
Data: Wed, 10 Apr 2013 13:01:12 -0700
Mittente: Rob Lanphier
Hi folks,
We've had at least a couple of site outages which we believe are due
to l10nupdate. The root cause is identified in a fairly old
ResourceLoader bug that seems to be biting us a little harder than it
normally does:
https://bugzilla.wikimedia.org/show_bug.cgi?id=27320
Disabling l10nupdate means that changes from Translatewiki.net will
not propagate to our websites as quickly as they normally do.
Depending on how long it takes us to fix this, it could be multiple
days.
Brad Jorsch is going to take a closer look at this issue
today/tomorrow, and hopefully identify the root cause. If he's able
to find the cause quickly, we may not need to disrupt the service, but
we're going to plan for the worst here.
Thanks (in advance) for your patience!
Rob
_______________________________________________
Wikitech-ambassadors mailing list
Wikitech-ambassadors(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors
*
Hello,
*
*
*
*
This is a reminder that the Language Engineering team will be hosting an
IRC office hour today, i.e. 10th of April 2013 at 1700 UTC/1000 PDT on
#wikimedia-office (Freenode). The agenda can be found in the section below.
*
*
*
*
Thanks
*
*
Runa
*
*
*
*
Agenda:
*
*
1.
Introductions
2.
Translate UX - Deployment and other news
3.
Language Mavens - an outreach initiative with the Wikimedia language
communities
4.
MediaWiki Language Extension Bundle (MLEB) Release
5.
Q/A - We shall be taking questions during the session. Questions can
also be sent to runa at wikimedia dot org <runa(a)wikimedia.org> before
the event and can be addressed during the office-hour.
*
---------- Forwarded message ----------
From: Runa Bhattacharjee <rbhattacharjee(a)wikimedia.org>
Date: Fri, Apr 5, 2013 at 3:07 PM
Subject: [Language Engineering] Office hour on 10th April 2013 at 1700
UTC/1000 PDT
To: mediawiki-i18n(a)lists.wikimedia.org, Wikimedia Mailing List <
wikimedia-l(a)lists.wikimedia.org>, wikitech-l(a)lists.wikimedia.org
*
Hello,
The Wikimedia Language Engineering team [1] invites everyone to join the
team’s monthly office hour on April 10, 2013. We have some exciting updates
about our ongoing projects, some of which have also been shared in our
recent blog posts[2]. During this session we would like to walk through
some of them. The team would also like to introduce a new outreach program
which was mentioned in the last office hour held on 13th March 2013 [3].
Event details and the general agenda is mentioned below.
See you all at the IRC office hour!
regards
Runa
Event Details:
==========
Date: 2013-04-10 (Wednesday)
Time: 1700 UTC, 1000 PDT
IRC channel: #wikimedia-office on irc.freenode.net
Agenda:
1.
Introductions
2.
Translate UX - Deployment and other news
3.
Language Mavens - an outreach initiative with the Wikimedia language
communities
4.
MediaWiki Language Extension Bundle (MLEB) Release
5.
Q/A - We shall be taking questions during the session. Questions can
also be sent to runa at wikimedia dot org <runa(a)wikimedia.org> before
the event and can be addressed during the office-hour.
[1] http://wikimediafoundation.org/wiki/Language_Engineering_team
[2]
http://blog.wikimedia.org/c/technology/features/internationalization-and-lo…
[3] http://meta.wikimedia.org/wiki/IRC_office_hours/Office_hours_2013-03-13
*
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
*
Hello,
The Wikimedia Language Engineering team [1] invites everyone to join the
team’s monthly office hour on April 10, 2013. We have some exciting updates
about our ongoing projects, some of which have also been shared in our
recent blog posts[2]. During this session we would like to walk through
some of them. The team would also like to introduce a new outreach program
which was mentioned in the last office hour held on 13th March 2013 [3].
Event details and the general agenda is mentioned below.
See you all at the IRC office hour!
regards
Runa
Event Details:
==========
Date: 2013-04-10 (Wednesday)
Time: 1700 UTC, 1000 PDT
IRC channel: #wikimedia-office on irc.freenode.net
Agenda:
1.
Introductions
2.
Translate UX - Deployment and other news
3.
Language Mavens - an outreach initiative with the Wikimedia language
communities
4.
MediaWiki Language Extension Bundle (MLEB) Release
5.
Q/A - We shall be taking questions during the session. Questions can
also be sent to runa at wikimedia dot org <runa(a)wikimedia.org> before
the event and can be addressed during the office-hour.
[1] http://wikimediafoundation.org/wiki/Language_Engineering_team
[2]
http://blog.wikimedia.org/c/technology/features/internationalization-and-lo…
[3] http://meta.wikimedia.org/wiki/IRC_office_hours/Office_hours_2013-03-13
*
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
Here are the current plans for i18n deployment next Tuesday (2013-04-09).
https://bugzilla.wikimedia.org/46840
* Update Translate Solr schema so that Special:SearchTranslations
actually works on Wikimedia sites using Translate.
* If the patch to operations is not merged and deployed in time this
will be postponed or I might request separate deployment window to
rebuild the data.
https://bugzilla.wikimedia.org/46754
* Enable WebFonts on Dhivehi projects (dv.wikipedia and dv.wiktionary)
https://bugzilla.wikimedia.org/43359
* Enable WebFonts on the Javanese projects
https://bugzilla.wikimedia.org/25326
* Devanagari transliteration tool for Bhojpuri Wikipedia
-Niklas
