Wikimedia blog

News from the Wikimedia Foundation and about the Wikimedia movement

Posts Tagged ‘uls’

Webfonts: Making Wikimedia projects readable for everyone

Wikimedia wikis are available in nearly 300 languages, with some of them having pages with mixed-script content. An example is the page on the writing systems of India on the English Wikipedia. We expect users to be able to view this page in full and not see meaningless squares also known as tofu. These tofu squares represent letters written in the language, but cannot be rendered by the web browser on the reader’s computer. This may happen due to several reasons:

  • The device does not have the font for the particular script;
  • The operating system or the web browser do not support the technology to render the character;
  • The operating system or the browser support the script partially. For instance, due to gradual addition of characters in recent Unicode versions for several scripts, the existing older fonts may not be able to support the new characters.

Fonts for most languages written in the Latin script are widely available on a variety of devices. However, languages written in other scripts often face obstacles when fonts on operating systems are unavailable, outdated, bug-ridden or aesthetically sub-optimal for reading content.

Using Webfonts with MediaWiki

To alleviate these shortcomings, the WebFonts extension was first developed and deployed to some wikis in December 2011. The underlying technology provides the ability to download fonts automatically to the user if they are not present on the reader’s device, similar to how images in web pages are downloaded.

The old WebFonts extension was converted to the jquery.webfonts library, which was included in the Universal Language Selectorthe extension that replaced the old WebFonts extension. Webfonts are applied using the jquery.webfonts library, and on Wikimedia wikis it is configured to use the fonts in the MediaWiki repository. The two important questions we need answered before this can be done are:

  1. Will the user need webfonts?
  2. If yes, which one(s)?

Webfonts are provided when:

  • Users have chosen to use webfonts in their user preference.
  • The font is explicitly selected in CSS.
  • Users viewing content in a particular language do not have the fonts on their local devices, or the devices do not display the characters correctly, and the language has an associated default font that can be used instead. Before the webfonts are downloaded, a test currently known as “tofu detection” is done to ascertain that the local fonts are indeed not usable. The default fonts are chosen by the user community.

Webfonts are not applied:

  • when users choose not to use webfonts, even if there exists a valid reason to use webfonts (see above);
  • in the text edit area of the page, where the user’s preference or browser settings are honored.

See image (below) for a graphical description of the process.

‘Tofu’ Detection

The font to be applied is chosen either by the name of the font-family or as per the language, if the designated font family is not available. For the latter, the default font is at the top of the heap. However, negotiating more complex selection options like font inheritance, and fallback add to the challenge. For projects like Wikimedia, selecting appropriate fonts for inclusion is also of concern. The many challenges include the absence of well-maintained fonts, limited number of freely licensed fonts and rejection of fonts by users for being sub-optimal.

Challenges to Webfonts

Merely serving the webfont is not the only challenge that this technology faces. The complexities are compounded for languages of South and South-East Asia, as well as Ethiopia and few other scripts with nascent internationalization support. Font rendering and support for the scripts vary across operating system platforms. The inconsistency can stem from the technology that is used like the rendering engines, which can display widely different results across browsers and operating systems. Santhosh Thottingal, senior engineer for Wikimedia’s Language Engineering team who has been participating in recent developments to make webfonts more efficient, outlines this in greater detail.

Checkbox in the Universal Language Selector preferences to download webfonts

A major impact is on bandwidth consumption and on page load time due to additional overhead of delivering webfonts for millions of users. A recent fallout of this challenge was the change that was introduced in the Universal Language Selector (ULS) to prevent pages from being loaded slowly, particularly when bandwidth is a premium commodity. A checkbox now allows the users to determine if they would like webfonts to be downloaded.

Implementing Webfonts

Several clever solutions are currently in use to avoid the known challenges. The webfonts are prepared with an aim to create comparatively smaller footprints. For instance, Google’s sfntly tool that uses MicroType Express for compression is used for creating the fonts in EOT format (WOFF being the other widely used webfont format). However, the inherent demands of a script with larger character sets cannot always be overridden efficiently. Caches are used to reduce unnecessary webfonts downloads.

FOUT or Flash Of Unstyled Text is an unavoidable consequence when the browser displays text in dissimilar styling or no text at all, while waiting for the webfonts to load. Different web browsers handle this differently while optimizations are in the making. A possible solution in the near future may be the introduction of the in-development WOFF2 webfonts format that is expected to further reduce font size, improve performance and font load events.

Special fonts like the Autonym font are used in places where known textlike a list of language namesis required to be displayed in multiple scripts. The font carries only the characters that are necessary to display the predefined content.

Additional optimizations at this point are directed towards improving the performance of the JavaScript libraries that are used.


Several technical solutions are being explored within Wikimedia Language Engineering and in collaboration with organizations with similar interests. Wikipedia’s sister project Wikisource attempts to digitize and preserve copyright-expired literature, some of which is written in ancient scripts. In these as well as other cases like accessibility support, webfonts technology allows fonts for special needs to be made available for wider use. The clear goal is to have readable text available for all users irrespective of the language, script, device, platform, bandwidth, content and special needs.

For more information on implementing webfonts in MediaWiki, we encourage you to read and contribute to the technical document on

Runa Bhattacharjee, Outreach and QA coordinator, Language Engineering, Wikimedia Foundation

The Autonym Font for Language Names

When an article on Wikipedia is available in multiple languages, we see the list of those languages in a column on the side of the page. The language names in the list are written in the script that the language uses (also known as language autonym).

This also means that all the appropriate fonts are needed for the autonyms to be correctly displayed. For instance, an article like the one about the Nobel Prize is available in more than 125 languages and requires approximately 35 different fonts to display the names of all the languages in the sidebar.

Language Autonyms

Initially, this was handled by the native fonts available on the reader’s device. If a font was not present, the user would see square boxes (commonly referred to as tofu) instead of the name of a language. To work around this problem, not just for the language list, but for other sections in the content area as well, the Universal Language Selector (ULS) started to provide a set of webfonts that were loaded with the page.

While this ensured that more language names would be correctly displayed, the presence of so many fonts dramatically increased the weight of the pages, which therefore loaded much more slowly for users than before. To improve client-side performance, webfonts were set not to be used for the Interlanguage links in the sidebar anymore.

Removing webfonts from the Interlanguage links was the easy and immediate solution, but it also took us back to the sup-optimal multilingual experience that we were trying to solve in the first place. Articles may be perfectly displayed thanks to web fonts, but if a link is not displayed in the language list, many users will not be able to discover that there is a version of the article in their language.

Autonyms were not needed just for Interlanguage links. They were also required for the Language Search and Selection window of the Universal Language Selector, which allows users to find their language if they are on a wiki displaying content in a script unfamiliar to them.

Missing font or “tofu”

As a solution, the Language Engineers came up with a trimmed-down font that only contains the characters required to display the names of the languages supported in MediaWiki. It has been named the Autonym font and will be used when only the autonyms are to be displayed on the page. At just over 50KB in size, it currently provides support for nearly 95% of the 400+ supported languages. The pending issues list identifies the problems with rendering and missing glyphs for some languages. If your language misses glyphs and you know of an openly-licensed font that can fill that void, please let us know so we can add it.

The autonym font addresses a very specific use case. There have been requests to explore the possibility of extending the use of this font to similar language lists, like the ones found on Wikimedia Commons. Within MediaWiki, the font can be used easily through a CSS class named autonym.

The Autonym font has been released for free use with the SIL Open Font License, Version 1.1.

Runa Bhattacharjee, Outreach and QA coordinator, Language Engineering, Wikimedia Foundation

Universal Language Selector (ULS) deployed on more than 150 wikis

The Universal Language Selector (ULS), a MediaWiki extension to configure language settings, has now been deployed on more than 150 Wikimedia wikis. Deployment started with the first phase on June 11, and over 5 phases it will be made available on all Wikimedia wikis. ULS replaces the extensions Narayam and WebFonts which were used to configure input and font settings respectively.

Click on the image to play a short video about typing in Telugu using ULS; created by Subhashish Panigrahi

During the last two development sprints, the Wikimedia Language Engineering team worked with the wiki communities to resolve critical bugs and enhancement requests, and to test features, and we communicated widely while completing 2 more phases of deployment. In the 2nd and 3rd phases, deployment was completed for Wikipedia wikis ranked in size between 11-20 and for wikis with no language versions.

User setting features were tested in major web-browsers and operating systems. This includes recent versions of Mozilla Firefox, Google Chrome, Internet Explorer, Safari and Opera. The tests were manually done using a test plan based on user scenarios for different functionality.

The announcement on Meta-Wiki is also available in more than 40 languages. This announcement page will be used for all deployment phases. Prior to deployment, all the updated wikis were informed about the this change simultaneously on their respective community portals.

Besides the wikis, the current version of the ULS can be viewed and tested on the beta installation of the English language Wikipedia. Bug fixing and integration testing will continue. The test steps can be used to verify the functionality.

Next phase of deployment

On July 2, 2013, ULS will be deployed on the English Wikipedia. More information about the Universal Language Selector can be found on the feature page, and the FAQ. Feedback can be sent using Bugzilla, via the mailing list, and on IRC (#mediawiki-i18n on freenode). The deployment of this extension was also discussed and queries were addressed during our last office hour (complete log of discussion). The Language Engineering team will be following up with more announcements, translation requests and Village Pump/Community Portal interactions to optimize the Universal Language Selector on the wikis.

Runa Bhattacharjee, Outreach and QA coordinator, Language Engineering

Universal Language Selector coming to all wikis

The Universal Language Selector (ULS) provides a flexible way to configure and deliver language settings like interface language, fonts, and input methods (keyboard mappings). It combines the features of two earlier Mediawiki extensions Narayam and WebFonts. From June 11, 2013 on, ULS will be made available to all Wikimedia wikis in 5 phases.

In the first phase, ULS will replace the Narayam and WebFonts extensions on 84 wikis. User preferences from the replaced extensions will not be preserved. Affected communities will be notified by the Wikimedia Language Engineering team of the upcoming change.

In the 5 weeks that follow, ULS will be deployed on Wikipedias in size 11-20 (phase 2), all projects without language versions (phase 3), English language Wikipedia (phase 4) and all other wikis (phase 5).

The Universal Language Selector can be visible in two ways: In the sidebar for wikis with language versions, like Wikipedia, or in the personal toolbar at the top of wiki pages for wikis without language versions, like Wikimedia Commons and Meta-Wiki. Based on the geographic location of users, the initial set of language preferences is presented. Users can set the input methods and fonts to that they want to use. Logged-in users can also change the language for the MediaWiki menu items.

Universal Language Selector is already available on several Wikimedia wikis like Wikimedia Commons and Meta-Wiki. The appearance on wikis like Wikipedia is available in the beta installation of the English language Wikipedia on Wikimedia Labs. A cog icon is present in the “Languages” section of the sidebar menu. Clicking the icon opens the Language settings panel that can be used to set the display and input settings.

Please have a look at the Universal Language Selector feature description or the Frequently Asked Questions for more detailed information.

Runa Bhattacharjee, Outreach and QA coordinator, Language Engineering

Language Engineering Development Updates and Events

In the recently concluded development sprint, the Wikimedia Language Engineering team fixed critical bugs for the Universal Language Selector, participated in several events around the world and also announced the release of the latest version of the MediaWiki Language Extension Bundle.

MediaWiki Language Extension Bundle and Updates to ULS

As the date for the first phase of deployment of Universal Language Selector (ULS) draws close, the team has been fixing critical bugs and testing the fixes. These included bugs related to the behavior of the ULS activation ‘cog’ icon. Significant design changes were also made on the input settings panel. Additionally, ULS has been hidden for users who do not use JavaScript on their browsers.

These updates are also part of the latest version of MediaWiki Language Extension Bundle (MLEB). Besides ULS, miscellaneous maintenance bugs were fixed for the Translate extension editor. This further improves the stability of the Translation Editor – TUX. CLDR has been updated to version 23.1.

Amsterdam and Tel-Aviv Hackathons and Community Programs

Members of the Language Engineering team participated and also helped in organizing hackathons at Amsterdam and Tel Aviv. At the hackathon in Amsterdam, organized by Wikimedia Nederland, team members interacted with their peers. Besides attending the workshops, they also submitted and merged patches for various internationalization extensions. A session for automated browser testing with the Wikimedia QA team was particularly well-received in view of the upcoming ULS deployment.

At the hackathon organized by Wikimedia Israel, Amir Aharoni led the event and brought together more than thirty local participants to explore various aspects of contributing to MediaWiki projects. The full report of the accomplishments from the event has been documented by him.

Alolita Sharma presented a talk about Internationalization in Wikimedia projects at IMUG. The entire video of the talk and presentation slides are available online.

Google Summer of Code

The Language Engineering team also welcomed the 4 students who will be participating in Wikimedia’s Internationalization projects for this year’s Google Summer of Code (GSoC). They will be contributing to the jQuery.ime project, Language Coverage dashboard, mobile app for Translate and right-to-left support on VisualEditor.

Coming up

Preparations for deployment of ULS and extending support to the GSoC candidates during the community bonding period are important focus areas during the next 2 weeks.

For information about the Language Engineering team and our projects, please write me at runa at wikimedia dot org or find team members on our IRC channel #mediawiki-i18n on Freenode.

Runa Bhattacharjee, Outreach and QA coordinator, Language Engineering

Getting ready for ULS everywhere

The Wikimedia Language Engineering team recently completed their latest development sprint, with a special focus on preparing for the upcoming deployment of the Universal Language Selector (ULS) extension on multiple wikis. The team also hosted a ULS-specific office hour on May 8, 2013 (logs).

ULS deployment prep

The Language Engineering team is working on refining several important features of the Universal Language Selector. This extension will provide an umbrella of services including selection of UI language, input tools and fonts. ULS will superannuate Narayam and Webfonts to provide a unified solution for configuring language settings for MediaWiki. During this development sprint, critical bugs related to positioning of ULS’ activation area and its “cog icon” label were fixed. These affected multiple MediaWiki skins and interlanguage wiki pages. The improved version will be deployed over several phases. More information about the upcoming deployment can be found in the deployment schedule.

ULS testing

ULS features are to be verified based on the test scenarios identified. These scenarios, based on the Cucumber framework, can be adapted for automatic as well as manual testing. The scenarios cover core features of ULS: triggers, language settings panel, display settings, font selection and input tools selection. These have been written in a simple “Given-When-Then” format and provide the steps for easy walkthroughs. The testing instance hosts all the latest updates that are being made. The team is looking for volunteers who can help us with testing and reporting bugs. Let us know if you would like to join and help (write to runa at wikimedia dot org or ping us on #mediawiki-i18n) .

What’s next

The team will be completing all feature changes and testing them by end of the current sprint to be ready for kicking-off the roll-out of phase 1 of ULS. Roll-out will be coordinated by Niklas Laxström with administrators of all scheduled wikis. The team will also be hosting a bug triage session on May 29, 2013 on IRC on the #mediawiki-i18n channel.

ULS is live on Commons!

Meanwhile, based on consensus reached by the Commons community, Universal Language Selector and the Translate extensions have been enabled on Commons.

For more details about the Language Engineering projects and ways to participate, please write to me [runa at wikimedia dot org] or ping us on #mediawiki-i18n.

Runa Bhattacharjee, Outreach and QA coordinator, Language Engineering

Updates from Language engineering: changes to the Language Selector, new Extension Bundle release

In the recently concluded development sprint, the Wikimedia Language Engineering team made a new release of the Mediawiki Language Extension Bundle (MLEB), fixed bugs related to the Page Translation feature in Translate UX (TUX) and began work on design changes for the Universal Language Selector (ULS). The team also hosted a bug triage session that was well attended.

Input Settings from the ULS Language Settings Panel

Universal Language Selector Design Changes

Development and design changes have been initiated for the Universal Language Selector. The option to position the extension’s main panel in the sidebar was added and this feature is now being polished. Changes to the layout of the Language Settings dialog have been initiated, and usability tests for the proposed design changes were also done.

Using Wikimedia’s default GeoIP locator, ULS can now infer the user’s location and suggest language preferences.

MLEB Release

The April release for the Mediawiki Language Extension Bundle (MLEB) was announced by Amir Aharoni. Starting with this release, MLEB is no longer compatible with MediaWiki 1.19. MLEB 2013.04 and its later versions can only be used with MediaWiki version 1.20.4 or above.

The notable changes include update to CLDR v.23, bug fixes to further stabilize TUX and design changes for the Universal Language Selector. An experimental feature to present a restricted translation environment for new translators was developed for TUX. This is not enabled by default. Basic support for the XLIFF file format has also been added to Translate.

Up Next

During the next development cycle, the team will complete the changes to the Universal Language Selector design and test the features. The team is also participating in Google Summer of Code (GSoC) and the Outreach Program for Women (OPW), and will be working on completing the tasks in the next stages of the programs. More information about the other open projects for internationalization can be found in the master list.

The next Language Engineering office hour will be held on 8 May 2013 at 17:00 UTC (10:00 PDT) in #wikimedia-office on Freenode IRC.

Runa Bhattacharjee, Outreach and QA coordinator, Language Engineering

Universal Language Selector now has Input Methods

The Language Engineering team at the Wikimedia Foundation works on a set of tasks every two weeks. This post is about the team’s accomplishment over the past two weeks. 

Have you ever sat at a computer in a foreign country, and wondered how you were going to enter text in your language using a keyboard with a different alphabet?

“Input methods” are interfaces that allow users to enter text in a script different from the one used on their keyboard. On some Wikipedia versions (like wikis in Indic languages), such a tool has been available through the Narayam extension.

As part of Project Milkshake, this feature has recently been exported to a JavaScript library (a bundle of code, called jquery.ime) so that it could be reused by other web developers.

Another language-related tool, the Universal Language Selector (ULS), allows readers of Wikipedia and its sister sites to easily pick the language of their choice for the website’s interface.

Over the last two weeks, we’ve integrated the input methods’ functionality directly into the Universal Language Selector: it now comes with a large set of input tools that users can use to input text in non-latin languages.

The integration of the two tools makes the interface more consistent and usable when it comes to choosing languages in which to read (“display”) and to write (“input”) on the site: both settings are located in the same dialog of the Universal Language Selector.

When selecting a language in which to write, it’s possible to set an accompanying preferred input method for that language, if available. When input methods have been assigned to different writing languages, switching between languages in the menu will automatically change to the preferred input method for that language.

Other language engineering news in brief:

  • The Language Engineering team will be in India during the second week of November to participate in the OpenSource Language Summit in Pune, and the Wikimedia DevCamp in Bangalore. For new volunteers who want to get started contributing to our tools, we’ve prepared a list of bugs that you can work on at these events with our support.
  • We’ve also worked on finalizing the development plan and features for Translate UX improvements, which were identified by user testing with volunteer translators to improve translation efficiency.
  • We’ve worked on how to get metrics on the impact of our tools through URL-based usage data gathering. Feedback is welcome.
  • We’ve fixed some bugs related to the ULS and gender support in MediaWiki and MediaWiki extensions.
  • The Narayam and Webfonts extensions were deployed to Wikimedia sites in Marathi; Narayam was also deployed to sites in Amharic.
  • An early stable version of ULS was deployed on Wikidata; this first use on a production site revealed a few bugs that were fixed. It will be updated to the latest stable version periodically.

Srikanth Lakshmanan
Internationalisation/Localisation Outreach / QA Engineer

Designing for the multilingual web

User testing is essential for designing multilingual interfaces, even though it can be a time-consuming process: it ensures that the community of users are part of the design process. In this article, we share lessons learned by the Language Engineering team while designing features and interfaces that empower users to read and edit Wikipedia and its sister sites in many languages.

Designing user interfaces for the Wikimedia world comes with a lot of responsibility. To achieve our mission, we need to make sure we think of users with varying levels of technological expertise and language skills. While the internet can be a very friendly place for those who understand English, it could be like navigating the Greek Wikipedia to the 4.4 billion people who do not.

While designing the user interface (UI) for language tools like the Universal Language Selector (ULS) and Translate extension, we needed to make sure it could be understood and used by those who use the internet in languages other than English. We had to create early representations of the interface, link them together to create interactive prototypes and test them with users. Each of these steps presents various challenges in a multilingual environment.

Design tools generally have poor support for non-Latin scripts. Moreover, creating screens and prototypes in languages that you don’t speak is hard. But since the world needs these language tools, we can’t wait for our design software to improve, we just need to figure out our own ways to get things done.

Creating multilingual mock-ups

UI designers make layout comps early in the process to illustrate how the interface elements and content will be arranged.

While designing the ULS (that will display a massive list of languages), the only way to understand the effectiveness of the layout was to simulate the end result with all the language names. Common graphic design suites are not optimized to manage large number of text elements and have issues when working with non-Latin fonts.

Our workaround: After some exploration, we realized that the most painless way of creating comps that have multilingual text is to render them outside the design software:

  • Create the UI layout using your design tool;
  • Use a template language like mustache to include placeholder text within the mockup and export them as SVGs;
  • Create a translation text file to replace the placeholder text with strings in your language;
  • Perform a string replace in the SVG and rasterize it with inkscape using a script.

There is a neat illustration of the entire process in this video by Pau Giner. This process allowed us to quickly experiment and test comps in many languages by giving the text file to a translator.

Making interactive prototypes

The best way to understand if a design is effective is to observe a user using it. The fastest way to do this is to make click-through prototypes that simulate a workflow. When our multilingual comps were ready, the next task was to package them and link them by hotspots. Most of the popular tools to do this are not free. After scouting around for free alternatives, we chose a Firefox extension called Pencil because it:

Translate extension prototypes in Malayalam

  • imports raster and vector images, including copy-pasting from other design tools;
  • features master pages and a component library to reuse graphic elements;
  • has rich text support;
  • exports to a single HTML which simulates a web page experience;
  • is free and open-source.

It fulfills our requirements, even though there are a few annoying quirks in the interface which could be improved. Check out this interactive presentation of the ULS that was created using Pencil.

Remote user testing

Once our prototypes are ready, it’s finally time for the real test, with users from parts of the world where the primary language is not English (roughly 95 percent of the world’s population). Planning the logistics and schedule of remote user testing can be tricky, so here are a few key points to keep in mind:

Remote user test

  • Create a pool of volunteer user testers early in the design process. Getting a tester is usually a hit and miss, so it helps to have a volunteer base that can be easily reached when needed.
  • Tell users what the test is about. Most users will not know what happens in a user testing session and may be afraid to volunteer. Who likes to be tested anyway? We created this guide to better communicate what the sessions were about.
  • Schedule the tests initially and ask for a confirmation. We found that testers may not be available at the scheduled time and they often want to reschedule. Stay friendly and accommodating, as these people are providing you with valuable feedback.
  • Observe using a platform that meets your requirements. We found Google+ Hangouts to be the service of choice due to its ease of use across operating systems. As a bonus, it can automatically create a YouTube video of the whole session.
  • Inform the tester beforehand on privacy issues. If you want to share the observations publicly, make sure the tester knows and has agreed to those terms.
  • Have fun. Keeping the mood light with initial introductions will help to make the tester feel comfortable and give more feedback.

If you are curious, you can watch this video from our latest test sessions of the ULS to understand how we do it.

We are designing and developing your software, so keep the feedback coming!

Arun Ganesh and Pau Giner
UI/UX Designers, Language Engineering Team

Language Engineering: Input methods and Visual Editor

The Language Engineering team at the Wikimedia Foundation works on a set of tasks every two weeks. This post is about the team’s accomplishment over the past two weeks. You can also check the slides of our demonstration.

jQuery.ime: Wikimedia wikis use Extension:Narayam to support input of non-Latin text. As part of Project Milkshake, jQuery.ime is a generic input method tool ported from Narayam, which can be used even outside the Wikimedia universe. We have completed the development of jQuery.ime and this example demonstrates the plugin in action. It supports over 60 input methods across 32 languages. There is detailed technical specification and we welcome you to try out and contribute to the project by creating new input methods or reporting bugs. The next phase will be to integrate jQuery.ime with Universal Language Selector.

Internationalization requirements for VisualEditor: The VisualEditor will change the Mediawiki editing interface in a major way, making it much more user friendly. The Language Engineering team has a keen interest in making sure the VisualEditor supports all languages. We have written detailed Internationationalization and Bidirectional text requirements for the Visual Editor to support all languages, including right to left languages. Other available documents are a general test document, right to left test and Indic tests for testing input method compatibility with VisualEditor. Do perform these tests for your language and report bugs if you find them.

India Events: The Language Engineering team will be in India in early November participating in the OpenSource Language Summit in Pune and the Wikimedia DevCamp in Bangalore. If you are a developer interested in working on language related tools or Wikimedia Mobile, please sign up for the DevCamp. We will also meet up with community and talk about Language Engineering tools at the Language Engineering meetups in Pune and Bangalore. If you’re near, please sign up and we’ll see you there!

In brief:

  • Universal Language Selector got some bug fixes, including scrolling, choosing fonts, and it is now fully internationalized.
  • As mentioned in the previous blogpost, We have completed integrating Extension:Translate with CentralNotice. Some patch sets are awaiting code review. Unfortunately this feature might be missing in this year’s fundraising translations, due to other fundraising priorities.
  • We held IRC office hours (log) on October 17th. The next session is on November 21st.

Srikanth Lakshmanan

Internationalisation/Localisation Outreach / QA Engineer