Translatable modules/Engineering considerations
The Translatable modules project is trying to build a new framework for module localization.
This section is mostly about the considerations for the core MediaWiki and extension developers who will implement this framework.
Necessary changes in the Translate extension
[edit]- A new file format support (FFS) class may have to be developed for the message storage format that will be chosen.
- There must be a way for translation administrators to organize modules into categories that will be easy for translators to search. (This point is perhaps more about Scribunto and core MediaWiki than about the Translate extension, but the engineers will decide this.)
- The message group selector must be updated to show modules conveniently, according to the groups defined in the previous point.
- Will the modules need to be normal (tracked) message groups (like translatable pages), or can they be transient (messages list is created on the fly, but they are not tracked in Translate). They should probably need to be normal groups, and then the question is how do those groups get registered in the system? Manually or automatically? Do we need separate "mark" action like for translatable pages, or should updates be processed automatically (with risk of making mess in case of vandalism, etc.)?
Anything else?
Necessary changes in the Scribunto extension
[edit]- Standard Scribunto functions will probably have to be added for reading messages from the files. (See the “Standardization” section under principles.) “Standard” here means that these functions will be available on all wikis where Scribunto is installed. (It’s possible that this change or a part of it will actually be in Translate, and working on wikis where both Translate and Scribunto are installed.)
- Documentation updates.
Anything else?
Aspects related to Abstract Wikipedia / WikiLambda
[edit]The Abstract Wikipedia initiative aims to make it possible for communities to write cross-wiki functions to generate content in a multilingual fashion.
In the first phase, this content will be calculations and algorithmic output very similar to the current template and Lua system, with the internationalisation done manually on the central wiki where the functions are written. The subsequent phase envisions full textual content (clauses, short prose statements, or even full articles). This will use a combination of community-sourced language neutral data modeling and language aware linguistic modeling.
Any translatable user interface strings in Modules will have to co-exist with the content generated by Abstract Wikipedia. For example, in an infobox a Module may generate a table about a musician where one column represents the property names about the article's topic (these text of these property names may be translatable via the translatable user interface strings described in this document), and the other column has some property values generated by Abstract Wikipedia functions from a central wiki of functions, where appropriate (e.g., if some moderately complex processing needs to be performed on a mixture of prose and Wikidata properties). Later, subject to the interests and decisions of the editing communities on each wiki, the entire infobox may become a common function, provided and translated centrally for all wikis.
More information
[edit]- Discuss at Talk:Translatable modules.
- Stakeholders in the project
- Development and design principles
- Current solutions
- Proposed solutions - the part that needs the most discussion and review