Multimedia:Meeting in Paris/Notes/Multilingual Support
Appearance
Multi-lingual Support can benefit the approach from contents, structure, search and interface. Contents, structure, surface are inter-related and interface has effect on every aspect.
Workflow analysis
What's the current workflow related to this topic?
- MediaWiki interface is translated by the translation called, betawiki.net.
- Contents and some meta data are translated through wiki interfaces.
- Press releases etc are translated on meta
Major issues
What are the major issues related to this topic?
Interface
- Language-sensitive rendering is needed.
- Auto-detect of the language preference is not supported. For example, RTL switch is not available.
- Translation communities are scattered and need a central hub.
Content
textual page content
- translatewiki.net even for this?
The Translate extension maybe ...
It could make a big difference on Meta and Commons ...
- use twn community but store on commons
??
Templates (license-Tags, etc)
- translatewiki.net (experimental)
Media-Content
localized Subtitles
- Structure (Page titles, categories)
- Babel-Extension useful for translators, but also for commons
- Language settings (ui-lang, gender, skin, etc) not copied on first login (SUL)
- When a user creates a new profile on a wiki, many more of the aspects that relate to his profile should propagate for instance... gender, timeformat, skin, preferred language ... all as a default.. When a UI preference is changed, it should be asked if this change is to propagate.
- Coordination of translator communities (translatewiki vs. meta - transcom)
- Example, the fundraiser 2009 consists of meta texts and translatewiki.net UI messages. In order to get the whole done for one language both are to be done.. This is not considered. Consequently we have not an assured result.
- File name convention needs to be standardized.
- Rationale: File name in right-to-left is almost impossible to deal with left-to-right language users. However, imposing English naming convention is unfriendly to non-English users.
Search
Please see Search section for issues related with multi-lingual search
Tools and workarounds
What are the existing tools or workarounds used to circumvent these issues?
- Template-localization hack on Commmons (Multichill)
- Some fairly standard text like "license texts" are localised at translatewiki.net. However there are issues with this as the localisations should be Country specific for the big text...
- {{lang}} tags to indicate content language.
- When descriptions are stored with this tag for a language, we could show if these templates contain particular parameters that would indicate that they may need to be translated.. For instance.. Tropenmuseum Indonesia content with a Dutch text and no Indonesian text.
- Multilignual Image Search (Duesentrieb's WikiWord) [1]
- This is a great tool but it relies on the existence of Wikipedia articles. It would be good if Wiktionary content could be used in order to expand the values for languages.. There are issues but they have been solved... There are technical superior solutions that could contain both the Wikiword and the Wiktionary data.
Other possible solutions
What other solutions could be used to circumvent these issues? (Be bold and creative)
- standard templates (xml dump) to be imported into new wikis (esp. for smw support)
- notice-box, infobox, language-indicators, license tags, ...
- Use traslatewiki.net for both software interface, contents and editable meta data.
Solutions analysis
What are the advantages and drawbacks of these solutions? (existing or not yet)
- Efficiency in solving the issue
- Drawbacks
- Feasibility
- ...
Prioritization
What issues should we focus on?
- ...
- ...