#Chennai Hackathon

The Chennai hackathon has come and gone. There has been a report on the India mailing list. It is a wonderful report, many people who should be interested will not read it because they are not subscribed to it.

The projects people worked on were very diverse:

• Wikiquotes via SMS - @MadhuVishy and @YesKarthik
• API to Rotate Images (Mediawiki Core Patch) - Vivek
• Find list of unique Tamil words in tawiki - Shrinivasan T
• Program to help record pronunciations for words in tawikt
• Translation of Gadgets/UserScripts to tawiki - SuryaPrakash [[:ta:பயனர்:Surya_Prakash.S.A.]]
• Structured database search over Wikipedia - Ashwanth
• Photo upload to commons by Email - Ganesh
• Lightweight offline Wiki reader - Feroze
• Patches to AssessmentBar - gsathya
• Parsing Movie data into a database - Arunmozhi (Tecoholic) and Lavanya
• Random Good WP India article tool - Shakti and Sharath
• Fix bugs on tawiki ShortURL gadget - Bharath
• Add 'My Uploads' to top bar along with My Contributions, etc - SrikanthLogic
• WikiPronouncer for Android -  Russel Nickson
• Wiktionary cross lingual statistics - PranavRC

Most of these projects deserve attention of a larger public. They represent missing functionality or they have a different approach to something we are struggling with. They are all by people who have a keen interest in the projects of the Wikimedia Foundation and as such they represent our "latest generation". 

There is too much great stuff in this list to single out in this blog post. Then again, there is always the next blog post.

Thanks,

      GerardM

Translate reports of the #Hungarian #Wikimedia chapter

Like so many chapters, the Hungarian chapter writes monthly reports. Their main audience are the members of the chapter and for them Hungarian is a must. Many of the international partners and relations need the same report in English.

The Hungarian monthly reports are really needed in two languages. Having them translated in other languages would certainly be appreciated; the German WikimediaWoche for instance refers regularly to newly published chapter reports. This is a great argument for having reports translated in German. When people want to translate the Hungarian reports in another language, adding that language is only a click away.

Obviously many more chapters post their monthly reports you can also find them on chaptersplanet.org . Having the reports both in English and in the language of the land seems obvious. When more chapters translate their reports, it becomes relevant to translate the pages on Meta that point to these reports as well. This in turn will promote the translation of the reports of other chapters even more.
Thanks,
     GerardM

The #Santali language and the Ol Chiki script II

A request for a #Wikipedia is made for the Santali language. The request was made for use with the Latin script but Santali language is also written in the Ol Chiki script. It stands to reason that when a language is written in multiple scripts, it is relevant for the people who read that language to have fonts available for all the scripts in use. It is unlikely that the Ol Chiki font is part of any standard operating system.

When you are interested in an Ol Chiki font, one resource that pops up when you search for it is Wesanthals. Several fonts can be found at this website. Sadly they are not available under a standard free license. The good news is that we are reaching out to developers of Ol Chiki fonts.

When we do have fonts available under a free license, we can provide support for the Ol Chiki font in WebFonts. A text in Ol Chiki will be tagged like this:

<div lang="sat-olck"> ᱐</div> or <span lang="sat-olck"> ᱐</span>

Thanks,
     GerardM

#WebFonts for the #Tibetan #Wikipedia

Some time ago we enabled the Jomolhari font on translatewiki.net for the Dzonghka language. It is not only Dzonghka but also the Tibetan language,  Denzongkha and the Ladakhi language that use the Tibetan script.

Being able to support the Tibetan language is particularly relevant as there is a Wikipedia in this language. For this reason the Jomolhari font was enabled for Tibetan as well and we are now looking for confirmation from the Tibetan community that they are happy with the result.

As you can see on this user page at translatewiki.net, the standard text shows readable Tibetan thanks to the WebFonts extension. The text to the right in the Babel user information however shows the Unicode blocks. This indicates that WebFonts does not get triggered.

As you can see in the edit screen, the text is explicitly marked as Tibetan. When WebFonts is enabled on a Wiki and when Tibetan is configured  with one or more fonts, Tibetan will show properly. The HTML in the Babel user information however does not include a language attribute. It should.
Thanks,
       GerardM

#WebFonts on #Wikisource

As the #MediaWiki Webfonts extension has been implemented on the English language Wikisource, it provides all kinds of opportunities. What it does require is that you understand how things work.

There are a few things that are important:

• All web fonts are available where WebFonts is enabled
• When a text is properly tagged and a font exists the web font will be triggered
• People easily recognise different languages and different scripts. It is computers and search engines that really benefit from proper tagging. By inference our public does.
• As more freely licensed fonts become available for more scripts, including historic languages and scripts, the user experience of projects like Wikisource and Wiktionary will greatly improve

The Amiri font, a wonderful font for the Arabic script, recently became available in WebFonts. As it is so much prettier then the default font that exists on so many computers, I added the necessary tags to trigger Amiri as an example on one article in en.wikisource. What made my day is that the Wikisourcerers improved on what I did and have the English and Arabic text of the national anthem of Saudi Arabia side by side.

Thanks,
      GerardM

The #Santali language and the Ol Chiki script

At first the Santali language was hardly written and when it was, it was written in the Bengali alphabet, Oriya alphabet, or the Latin alphabet. As Santali is not an Indo-Aryan language (like most other languages in the north of India), Indic scripts do not have letters for all of Santali's phonemes, especially its stop consonants and vowels, which made writing the language accurately in an unmodified Indic script difficult. 

The  Ol Cemet', Ol Chiki or simply Ol was created in 1925 by Raghunath Murmu specifically for the Santali script one letter is assigned to each phoneme.

A Wikipedia has been requested for the Santali language and it will be localised in the script that is popular with most people. Apparently this is the Latin script. This does not mean that the Ol Chiki script is not relevant for use within a Santali Wikipedia.

There is a font that is available for free. Sadly it is not available under a free license. Finding the copyright holder for these fonts allows us to request a change of the license. Once the license is changed, we can make the font available as a web font.
Thanks,
     GerardM

#mlwlux - #Wikipedia, how many people do live in #Amsterdam

At the Multilingual Web conference in Luxembourg, it was mentioned that Amsterdam has a different number of people living there depending on what Wikipedia you are reading.

It needs a solution it was said. Yes it does and letting us know is part of a solution. It certainly allows the number for Amsterdam to become the same. A real solution would be one where such data is maintained centrally and served where ever it is needed.

The Wikidata project is starting and one of its objectives is to serve as a central data repository. The people at the conference will appreciate that it is not simple; 783.364 is the number quoted on the Dutch Wikipedia while an American would say that a number like 783,364 is quite a lot more.

Anyway; we do appreciate that the numbers game and the data game is very much something we have fun with in the near future.
Thanks,
      GerardM

#DBpedia and #Wikidata

At the #mlwlux conference, the new Wikidata project was discussed. The question raised was, what will that do to DBpedia. To understand, DBpedia is very big in the semantic web world and once Wikidata is going to maintain the data locally, it will affect DBpedia.

Given that the world changes around us anyway, the best thing that could happen for both Wikipedia, DBpedia and Wikidata is that we start actually using and considering the data aspects of the information that resides in Wikipedia.

Much of the data in DBpedia is retrieved from info boxes. What DBpedia is really good at is finding inconsistencies in those info boxes. When info boxes will transition to Wikidata based info boxes, all these inconsistencies will have to be addressed.  When we start now, it will improve consistency and quality in Wikipedia.

Such activity will give the DBpedia and the Wikidata communities a shared goal. Many of the people involved are member of all three communities. Really, once the data is used practically not only on the semantic web but also on the wiki everyone wins.
Thanks,
     GerardM

#multilingweb - #Arabic and #Hebrew are #RTL

Amir  asked me to ask at the Multilingual Web conference in conference to people like Richard Ishida:

"How hard would it be to allow assigning element directionality according to lang.  In HTML4 and in the current draft of HTML5, <span lang="ar"> has dir="ltr", unless specified otherwise, and I find it ridiculous". 

The usual replies Amir gets is:

• Backwards compatibility
• Many websites already use HTML-5 even though it is not a finished product. This will break them

His reply to this:

• If a document explicitly specifies that it's HTML5, it should have directionality assignment by default.
• Add an attribute to the root HTML tag, something like: <html dir="bylang"> or <html dirbylang="true">

Amir has aired his view before and an answer he gets from some "standards people" is: "It would be very problematic to do it, because most web developers don't use the lang attribute". This is rather funny because this will work only when the lang attribute is used.  And anyway at some point in time the public at large do not care really about previous versions of HTML as all the websites still in use will have moved on.

What we need is proper meta data for all languages and such data can hide very nicely inside a browser. Developers of websites do not know and want to know about all the linguistic niceties necessary to support a multi lingual web. It so many ways it makes sense to provide language support from inside the browser.

At the Wikimedia Foundation we we don't just support a lot of languages, we are also well aware of the languages we support. Ours is a world-wide community of people who have the opportunity to openly complain to us about bad support for their language and they expect that their complaint is actually read and is being taken care of.

Thanks,

     GerardM

#multilingweb - #i18N and #l10n testing framework

A subject for the conference about the Multilingual Web is what gaps exist in supporting a multilingual web. Obviously people who are living the multilingual web like my colleagues in the WMF localisation team suffer these gaps. Our team has been asked what to do next and one idea of Amir I love to put forward.

A testing framework for localization
I searched and I couldn't find any testing framework that is focused on localization. Many localization-specific issues must be tested, for example, grammatical correctness of generated messages, text readability in different scripts, support for encodings and fonts, etc. You can find a fuller list in Wikipedia (i wrote most of that section myself). It is possible to test all these things using the current frameworks, but much of it would be manual.

For example, i'm not familiar with any tool that would automatically or semi-automatically create screenshots of all the possible translated strings with their complete context. This would be useful for the translator, to see how to translate a message; for the developer, to see whether any message runs out of the screen or hides a button that must remain visible; and for the tester who speaks the language and wants to see whether all the generated messages are grammatically correct. Currently, a developer must do this manually;
it is time-consuming, inefficient, hard to plan and to maintain, and the fact is that the developers are hardly ever doing this.

Such a testing framework would be really great for so many organisations. At translatewiki.net we support many organisations with their internationalisation and localisation. A framework will make it easy to repeat the testing often. This will improve consistency and quality and makes for a great multi lingual experience.
Thanks,
     GerardM

#Wikimedia #Mobile Frontend is opening up

The mobile frontend of #Wikipedia achieved 9.5% of the total traffic. It is growing rapidly. Having a strategy to support your wiki on mobile platforms is really important. There was a bit of good news on the Wikitech mailing list:

[Wikitech-l] First steps at making MobileFrontend usable beyond the WMF infrastructure

 Over the last couple of weeks, I've taken a few steps to remove some of theWMF-specific bits of the MobileFrontend code base:https://bugzilla.wikimedia.org/show_bug.cgi?id=34144https://bugzilla.wikimedia.org/show_bug.cgi?id=34145

Also, now if you view an article with "useformat=mobile" in the URL's querystring, MobileFrontend will keep the mobile view enabled as you browse pageto page until you explicitly exit the mobile view.
While MobileFrontend has now been generalized enough to be used beyond theWMF cluster, there are still quit a few things that could be done toimprove the ease of out-of-the-box usage. For instance, adding configurableWURFL support (which I believe should be fairly straightforward - this isout of date but the same idea should still work:http://lists.wikimedia.org/pipermail/wikitech-l/2012-January/057478.html)or making it possible to use path-based modifiers to signify mobile view(eg http://mywiki.com/wiki/Article -> http://mywiki.com/wiki/m/Article -https://bugzilla.wikimedia.org/show_bug.cgi?id=35178).

It would be great if anyone can help test/provide feedback for the changesthat have been made, and especially if anyone wants to help add thefeatures mentioned above!

There are many organisations large and small who use MediaWiki. Many of them stand to gain a lot of traffic with out of the box support for mobile devices. The great thing of this effort is that the MobileFrontend will be supported in the next releases; it is what the WMF uses itself.
Thanks,
      GerardM

A #Wikimedia #storyteller is the new #Communications manager

There are many wonderful stories waiting to be told relating to any and all of the Wikimedia projects. When Matthew Roth one of the three storytellers transitioned into the role of Global Communication Manager, I asked him ten questions and as I am happy to have received his answers.
Thanks,
      GerardM

You were a storyteller for the last Fundraiser, how many stories were written and how many stories were used?

At the Wikimedia Foundation, the three Storytellers -- Victor Grigas, Aaron Muszalski, and I -- did approximately 220 interviews over 5 months. The Storytellers worked with the fundraising directors to narrow those interviews down to about 40 that we thought might make for good fundraising appeals. Of those, the managers of the fundraiser wrote appeals from 14 Wikipedia editors from around the world, in addition to the Jimmy Wales appeal (some Wikimedia chapters ran localized appeals with other people). We were very proud to show a more diverse and demographically disparate group of appeals than in past fundraisers and I think the goal will be to continue this trend moving forward in 2012 and beyond.

What story is behind a title of "global communications manager" role? Is it about communicating WMF or communicating Wikipedia ?

I think my staff page says it best: In the role of Global Communications Manager for the Wikimedia Foundation, I work to support the community of communications volunteers representing Wikimedia chapters around the world. With them, I help craft the global story of Wikipedia and the Wikimedia Foundation, while working to increase the population of editors, raise funds from our readers, and serve our enormous volunteer community. I'm accountable for promoting the Wikimedia Foundation mission and vision through our public communications materials, including press releases, our social media channels, and community listservs. Every day I have the privilege of conversing with the the dynamic community of Wikimedians, as well as the world’s top reporters, bloggers and thought leaders.

As there is a global audience, we may have to localise some messages to be really effective. What are your thought

Where possible Foundation messaging should be localized and reflect the audience. In many cases, Wikimedia chapters will be best positioned to communicate localized messages and influence our global message to better align with localized need. My role involves supporting this work at the Chapter level. Similarly for very active individuals who are not in formal chapters but who do very meaningful work to promote the health of the projects, I want to be sure their work is promoted.

There are many social media platforms. They are wildly popular and many Wikimedia related activity can be found on them. At the same time people say "Wikipedia is not a social media". I think this attitude does not help, what do you think

I think the Wikipedia community will debate the merits of incorporating more social platforms within the editing space and will arrive at solution that works for the various projects. There is probably a spectrum of what will or won't work across the different projects. In an anecdotal way, photowalks can be a great way to get photographers together to take photos and upload them to Commons and hackathons can work wonderfully for developers and programmers. Such social meet-ups might not be as effective in every situation for writing and editing Wikipedia.
For more standard social media platforms, like Identi.ca, Twitter, Facebook or Google +, the Foundation is having ongoing discussion about how to better utilize our assets. Even though the Facebook page has 1 million likes, for web properties as big and well-known as Wikipedia and sister projects, that's not very many people. Our Twitter account has a relatively tiny following, given the size and reach of the projects. For instance, @tinucherian, a communications member of the Wikimedia India Chapter, currently has 10,000 more followers than Wikipedia (this attests to his remarkable social media acumen, and to our underachievement as a large and worldwide entity).

These facts reflect the historical distance we've kept between Wikipedia and social media. There is no single staff member who is responsible for updating social media platforms, but rather the role is done by a committee of people from different departments.

How does your work relate to other people blogging about and reaching out the Wikimedia message

Again, I think it's safe to say social media has not historically been one of the highest priorities of the Foundation, so there have not been too many formal or informal relationships developed with bloggers or others in social media spaces. I think to the extent we can, the Foundation supports initiatives through the Community, Tech, and Global Development departments to support those improving Wikipedia projects and those committed to the Wikimedia mission and goals, but it is an open question how far we will go to embrace social media.

We do not communicate really about Commons, Wikibooks, Wiktionary, Wikisource ...

I don't have enough background to comment on this assertion. I personally use and rely on Commons often and greatly enjoy contributing photos there (though with work, I haven't had as much time as I would like to take or process photos). I hope to do a great deal to promote these projects where and when I can.

Issues like the extension of copyright are not so much a Wikipedia but very much a Commons, Wikisource and Wikibooks issue, should our movement take up this issue as it does affect our mission so much.

I'm not as well versed as some in the foundation about this, but our legal department often works in this space and promotes open licenses and free access. Our stance on Golan v. Holder -- that public domain works should not be taken from the public domain and returned to copyright -- is only the most recent example. If you want more detail on this, however, I'd have to defer to our legal team, as they know much more than I do. 

When "global" is in your title, reaching out to people who do not speak English is part of the job. What do you think about translation?

While I haven't been fully apprised of the extent of the translation work you and the localization team are doing for the Foundation, I think some of the most exciting work in the projects happens with translation. The MediaWiki Translate extension and translatewiki.net provide some of the more important tools for enabling successful translation of open source materials throughout the world. Their application in numerous platforms speaks to their importance. I certainly hope to learn more about the work as part of my job.

From the exposure I had to the translation infrastructure for the Wikimedia Fundraiser, I was amazed by the organization and cooperation among volunteers around the world who quickly and efficiently translated fundraising appeals and guaranteed the 2011 fundraiser was a remarkable success. 

I speak Spanish and Portuguese, so from a personal level, I'm very interested in language and translation. I often say that I learned the most about my native language, English, when I learned to speak and write in Spanish. For instance, I had no idea there was a subjunctive tense and that I constantly used it until I had to render my thoughts in another language where its usage is frequent and vital. I'm also very interested in linguistics and language formation in bilingual (or trilingual and beyond) children. My understanding of it is limited, but I've read some material about language formation and I always have it in the back of my head that I would love to take more classes in linguistics.

I am also interested in the politics of translation as it relates to what gets translated and published across different languages and in different countries, and what that means for cultural and political relationships. One of the more interesting classes I took on the issue was in 2003 at the Naropa Institute in Boulder, Colorado. The professor was a Mizrahi Jewish translator and publisher who talked a lot about the politics and culture behind what gets published and what doesn't in Hebrew. Completely opened my eyes to a power dynamic I didn't understand before.

With the rise of free knowledge and the ever eroding limits to publication, I think the dynamics of power have already shifted dramatically and will continue to shift. The ability to freely disseminate information and knowledge in ones own language, and the ability to have that translated into other language, can have significant socio-political implications. I'm probably not smart enough to really even understand how significant that is :) Feel free to point me to good reading on the issue, if you like.

Two of our regular bloggers followed the excellent workshop Siebrand gave on Translate our translation software, do you know it, have you used it

I have not used it.

You moved from telling stories to get us funding. Now all our stories and all our objectives is your domain. Do you have room to decide on what is hot and what is not?

I don't know about "hot" stories, but I am very interested in expanding the stories we tell about the Wikimedia movement and include as many engaging, thoughtful voices as possible. We are actively working to expand the public's understanding of the marvelous work that happens in the projects and the fascinating people behind them.

Matthew Roth
Global Communications Manager
Wikimedia Foundation

#Standards - A gap in plural support

#multilingweb

When you can speak only for fifteen minutes, there is so much you  do not have the time for. Issues that are relevant, things the conference is meant to address.

When I wrote about plural, a subject that is actively discussed on translatewiki.net, Niklas told me about his frustration that his inventory plural rules in various databases had not resulted in anything at all.

As the Multilingual Web conference explicitly asks to identify where standards and best practices cover our needs, this is certainly one that is relevant to us.

As the hashtag of the conference will surely find its way to twitter, this can be seen as an experiment; will people who will go to the conference see this and will there be some follow up at the conference.
Thanks,
     GerardM

PS Niklas will be at the conference as well

Supporting #plural in #gettext and #MediaWiki

Gettext, the #i18n module of the #GNU software, is and has been really import for the internationalisation and localisation of open and free software. To a large extend it is what is used by many localisation platform.

What gettext provides is technology. What it does not provide is the specific rules needed to implement the internationalisation for a specific language. When we bootstrapped plural support at translatewiki.net, we copied the rules from other applications to start of with.

The way plural is implemented for applications supported at translatewiki.net is well documented. When you read the documentation, it is clear that there is no consistency and these inconsistencies are documented.

One of our contributors, Lloffiwr is taking an active interest in the subject and is compiling a list that shows the MediaWiki plural rules for the languages enabled for localisation at translatewiki.net. Such a list informs our localisers what is expected of them when they localise a message with plural support.
Thanks,
     GerardM

The web is Multilingual - #multilingweb

Presenting at the conference about the Multilingual Web will be fun. When you read what the conference is about, what they ask presenters to include in their presentations is interesting:

• existing best practices and/or standards that are relevant
• new standards and best practices that are currently in development
• gaps that are not covered by best practices and/or standards

In so many ways, what we do is implement the best practices as we know them. We are establishing best practices and are running into the gaps of the standards regularly because no other project supports the 412 languages that have an existing Wikipedia or are requesting a Wikipedia. 

It is great for us to have two people at this conference; we will learn a lot from the other presenters and from the people who attend. We expect that many best practices are set into a professional environment. Our environment consists of dedicated volunteers. The monthly update to our community of localisers at translatewik.net has 4600 recipients. Our puzzle will be to adapt what we learn for our setting.

We want to learn about translation work flow, we want to discuss what to do about languages that are not yet supported in the CLDR. Most of all we want to learn what we do not know, our blind spots. 

Thanks,

     GerardM

Fixing #terminology in #translatewiki is easy

The most important objective of translatewiki.net is to make it easy for our localising community. Another really important objective is to make sure that we facilitate all the needs for our localisers.

When we learn that a particular community localises on their local wiki, we really want to understand why. When we do, we will look for a solution that will make localisers more efficient and preferably reconsider using translatewiki.

At this time localisation is done locally on the Sanskrit Wikipedia. The argument to do this is because a lot of work is going into deciding on the best terminology used. Once the community has decided on what word or phrase to use, the changes that reflect the decision are made locally one at a time.

Translatewiki offers an alternative that is much more efficient. It is possible to export the messages. The result is a text file in the "gettext" format and all it takes to replace the changed terminology is to use the tools available in any decent text editor. Once this is done, the updated file is uploaded to complete this task.

Every language on translatewiki.net has its portal page and the Sanskrit portal should include references to the used terminology. This will prevent a person new to localising Sanskrit from using the terminology that he or she likes best.

Obviously it is up to the Sanskrit community to do as they please. Localising in an environment dedicated to localisation makes the people involved in localisation more efficient. The benefits of  their work will be widely shared and the developers at translatewiki.net are eager to learn why their environment is not good enough. They will fix things where it is broken.
Thanks,
      GerardM

It is all #Malayalam to me

When you give me a text to read in a script like the Malayalam script, it is all the same to me. Like in the example below, I can recognised different elements; I recognise the user interface, I notice an introductory text followed by the text that is introduced. It is likely this way because it is after all text in the Malayalam Wikisource.

For automated systems like the ones employed by Google, recognising a script is easy; all characters of a script have their own number and it is just a matter of looking them up. This is what automated systems do really well.

They are, like me, not able to recognise that the bottom text in the example below is written in Sanskrit.

Automated systems can be helped by identifying texts using labels embedded in the text. Something like this: <div lang="sa">സംസ്കൃതം</div>. It helps Google but it will confuse its systems. The default script for Sanskrit is Devanagari and this is implied when you only use the language code. 

When the embedded label is like this <div lang="sa-Mlym">സംസ്കൃതം</div>, it will be clear that it is Sanskrit written in the Malayalam script. It will not only be clear to Google, it will also be clear to the WebFonts extension because it can be configured to use fonts for the Malayalam script in a Sanskrit text.
Thanks,
     GerardM

The #Mongolian #script

Have a look at the article "Mongolian script". Now do the same thing with another browser or use Chrome as your browser.

The blocks represent the Unicode characters and I do not have a Mongolian font on my system yet. What is really cool is that Chrome shows Mongolian correctly from top to bottom. So far the lack of support for top down text in browsers is what prevents us from figuring out what we need to do in MediaWiki.

It will be cool when top down scripts are supported in most modern browsers. It enables us to support the people who read the top down scripts as well and consequently it brings us closer to what we aim to achieve.
Thanks,
    GerardM

Transliterate when it grows your audience

The Chinese and the Serbian Wikipedia have one thing in common; their content is shown in one of the two scripts you can select from. In essence the process is simple; you change a text from one to another script using a fixed set of rules and the only difference is the script of the language. You do not change the orthography it should be just other characters saying the same thing.

Understanding this is quite important because transliteration is not to accommodate differences in dialects. Far from it. When dialects are expressed in the same script, the differences become easier to understand when there is no longer any confusion because of the different scripts.

The "InScript" input methods exist for the scripts of India. What makes them special is that the same sounds are placed at the same location. This makes typing in different scripts easy. This gives the impression that it should be relatively easy to transliterate between scripts.

Changing scripts for a text is of relevance for Sanskrit. Sanskrit is written in many scripts and when a text originated in a script different from Devanagari, many readers of such an original text are helped with a transliteration into a script they are familiar with. At the same time it helps people appreciate how broad a cultural base the Sanskrit language has.

When transliteration works for Sanskrit, it is likely that the same or similar routines will work well for languages like Konkani. At Silpa there is a tool where you can test transliteration. It is a work in progress; each script has many features that need attention.Custom logic need to be written sometimes for script pairs, sometimes for specific language attributes.

What would be cool is when someone works on this existing code for the transliteration of Indian scripts. It needs more work both on script specific rules and on languages specific rules.
Thanks,
     GerardM

#Twitter does #RTL

When Twitter started to support right to left languages in earnest, they did need localisation for their software. Given the relevance of Twitter a great localisation is important; many people will actually see it, use it.

With the implementation of RTL languages like Arabic, Farsi and Hebrew, and the simultaneous localisation there are many people who are exposed to the same issues and flaws in the software. What is so wonderful that all the people localising software find each other and work together. It is as a Saudi Wikipedian wrote on the Arabic village pump: "we all have the same problems".

Amir, one of my colleagues in the WMF Localisation team, does a fair amount of localisation on other projects in his own time. The one thing we learn from him is about cool features used in other localisation platforms.

What really pleases us is how often we learn how much the community model of translatewiki.net is valid. It does make a difference when people are not working on their own little island. Many applications are localising an upcoming release and this makes all these people testers as well. People learning together about issues and working together on solutions particularly with developers involved as well make for a perfect and agile software development environment.
Thanks,
     GerardM

Meet ProofreadPage a #MediaWiki extension for#Wikisource

The ProofreadPage extension is an essential tool for Wikisource. Essential because it is installed on every Wikisource. As you can see from the screen-print, it is a tool that helps with the work flow of transliterating a text to the computer. The example is an old French text and in yellow it says that the transliterated text conforms to the scan.

It is an essential tool with one potential problem: its primary maintainer ThomasV has abandoned it. With the upgrade to MediaWiki release 1.19 several bugs surfaced and they were documented on the Scriptorium of the English language Wikisource. This was done by one of the very active Wikisourcerers, user:Billinghurst.

This problem was signalled by Lars to several WMF notables. Indeed there are plenty bugs registered in Bugzilla for ProofreadPage including patches. It is however really cool to notice that Sumana is finding reviewers for them and it is wonderful to learn that ThomasV was only one of more then sevendevelopers committing code in the last couple of months.

Tender loving care is needed to make sure that it will continue to work well after the MediaWiki release 1.19 and it is wonderful to learn that Zaran indicated his willingness to take over as its primary maintainer. One of his first tasks is to identify the existing relevant patches and integrate them.

Thanks,

       GerardM

#Sanskrit, sources and scripts

According to the English #Wikipedia, the Sanskrit language is written in Devanāgarī, various Brāhmī-based alphabets, and the Latin script. Practically we assume that Sanskrit is written in the Devanagari script and for its Wikipedia that is fine.

When Sanskrit sources exist in many scripts or alphabets, and particularly when the Brahmi based alphabets are not in common use, it is even more interesting for the Sanskrit community to find freely licensed fonts for these alphabets.

Asokan Edict - Delhi Inscription

The Omniglot website provides a lists of different scripts used for Sanskrit

Writing system used to write Sanskrit

Brāhmi, Devanāgari, Grantha, Kharoṣṭhi, Śāradā, Siddham, Thai, Tibetan 

Syllabic alphabets / abugidas 

Ahom, Balinese, Batak, Bengali, Brahmi, Buhid, Burmese, Chakma, Cham, Dehong Dai, Devanagari, Dhives Akuru, Ethiopic, Evēla Akuru, Gondi, Grantha, Gujarati, Gupta, Gurmukhi (Punjabi), Hanuno'o, Hmong, Javanese, Kannada, Kharosthi, Khmer, Lanna, Lao, Lepcha, Limbu, Lontara/Makasar, Malayalam, Manpuri, Modi, New Tai Lue, Oriya, Pallava, Phags-pa, Ranjana, Redjang, Shan, Sharda, Siddham, Sindhi, Sinhala, Sorang Sompeng, Sourashtra, Soyombo, Sundanese, Syloti Nagri, Tagalog, Tagbanwa, Takri, Tamil, Telugu, Thai, Tibetan, Tocharian, Varang Kshiti

It may be that it is not only a Brahmi font that will add more value to the Sanskrit Wikisource for original texts in Sanskrit. An original text is written in its original script and such a script may have different styles. It is great that with the WebFonts extension we can truly provide an authentic experience. It is just a matter of having the freely licensed fonts and an expressed demand.
Thanks,
     GerardM

#Sanskrit #Wikisource will get WebFonts

Both the Sanskrit #Wikipedia and the Sanskrit Wikisource are written in the same language and the need for support for the language is the same.

As you can see, input methods are already available for the Sanskrit Wikisource and adding WebFonts on a Wikisource has much more potential. Historic texts were often written in a different style of the same script. With WebFonts it is possible to have multiple fonts available. When a specific font reflects the style at the time of a publication, it adds to an authentic experience.

One other fringe benefit is that text in a script that is supported by WebFonts can be indicated as being in the language and it will show up properly. We do not know of any Sanskrit sources including Cuneiform text but when there are, support for the Cuneiform web fonts can be invoked starting this Monday.
Thanks,
      GerardM

Supporting a #font for #Arabic II

In January I wrote about the Amiri font. I wrote that it should be easy to support it in the MediaWiki WebFonts extension. This turned out to be not correct. One of the older more intractable bugs, one where Niklas prefers Brion to be involved in working on a solution, is preventing its use.

The Amiri font is as beautiful as ever and, we have implemented it in tranlatewiki.net as an experiment because the latest developments in the browsers' Unicode compliance is improving the rendering substantially. An Arabic text showing the Amiri font can be found here and the source looks like this:

<div lang="arb" class="mw-content-rtl" style="font-size: xx-large">
* بسم الله الرحمن الرحيم
* حررد مييسن
* مُحَمَّد‎
</div>

the Amiri font with the Firefox nightly build

Do note that in this example we use the ISO-639-3 arb code and not the ISO-639-1 ar code.

When you look at it with the nightly Firefox build it looks good. With production browsers the quality is still lacking. A MediaWiki solution will not only make a difference for the Amiri font, it will also make a difference for the Arabic font provided with Windows XP. Such a solution requires expertise in the inner workings of the MediaWiki parser and Unicode.
Thanks,

     GerardM

A logo for #Wikisource

The "official" logo for Wikisource is a bit funny. It is an iceberg about to keel over. It has been the logo used on most Wikisource projects and apparantly I am not the only one who does not like it.

According to the bug 33907, the plan is for the Marathi Wikisource to have its own logo. It is very much a logo for the Marathi Wikisource and it needs some adaptation when it is to be used for the Gujarati Wikisource.

What I would like is to have the logo for Wikisource revisited. The Marathi example is more obvious for a source project. It beats an iceberg that reminds people of the Titanic any day.
Thanks,
     GerardM

New templates for new #Wikimedia projects

People do request new languages on Meta. When a new language is requested, people will have to comply with a series of requirements. They are things like the localisation of messages, the writing of a few hundred articles that allow us to assess if what is written is really in that language..

When the requirements are met, when the members of the language committee are happy with the results, an e-mail is send to the chair of the board of the Wikimedia Foundation with the recommendation to approve the new project. Typically these recommendations are followed.

The next step in this workflow is the creation of a bug in bugzilla requesting the creation of the new Wiki. At that time specific technical information is needed. This information is needed by the Wikimedia engineers to create the project.

Robin made changes to the template and, we have changed the request for the Gujarati Wikisource. This request is in the final stage and we want to learn if the changes to the template make it easier to complete the necessary information.
Thanks,
      Gerard

#Lohit fonts progress to #release 2.5.1

Thanks to the wonderful work by #RedHat engineers, the Lohit fonts will continue to be the preferred fonts for many languages of India in the MediaWiki WebFonts. When you read the announcement you can understand why:

Hi All,
 Announcing the Lohit fonts 2.5.1 release. Following are the highlights.
- Support for Characters added in Unicode 6.0 in Devanagari, Bengali, Malayalam and Oriya scripts and Devanagari Extended. 

- Release of Lohit Marathi and Nepali with language specific shapes.
 Please note here Lohit Devanagari has localize characters for Marathi
and Nepali with locl feature of Open Type fonts and one can access it
with specific LANG.
 Still we have released these fonts since some rendering engine (qt,
icu) still not supporting locl feature and second is user using en_US
locale can not access language specific characters from Lohit Devanagari.

- Releasing lohit-ttf tarball consisting all lohit fonts ttf
 This is for easy installation of all lohit fonts together. One can now
download it and simply copy all ttf fonts in required folder.

- Major bugfixes in Telugu, Kannada, Assamese, Punjabi.
 For further details see Changelog released with each language. 

I am working on Lohit Tamil fonts will release it soon with Lohit
Tamil Classical font.

The members of the WMF localisation team are really pleased; many of the issues we raised at our meeting in Pune have been dealt with. These issues became known to us because of the feedback of the people testing at translatewiki.net.

The 2.5.1 Lohit fonts are going to be installed at translatewiki.net for review in the next sprint.
Thanks,
      GerardM