Difference between revisions of "Translation"

From Organic Design wiki
(nifty translation wikis: dotsub)
(i18n)
 
Line 40: Line 40:
  
 
== i18n ==
 
== i18n ==
Another thing to consider with multilingual wiki/CMS is the messages aspect. In our system we're providing a lot of templates and forms which include content that requires multiple languages. For this type of content, the i18n messages are the best place to maintain them so that they can be easily integrated with the translation community.
+
Another thing to consider with multilingual wiki/CMS is the messages aspect. In our system we're providing a lot of templates and forms which include content that requires multiple languages. For this type of content, the [http://www.mediawiki.org/wiki/Localisation i18n messages] are the best place to maintain them so that they can be easily integrated with the translation community.
  
 
The "MediaWiki" namespace is a special namespace which is used to interface with the ''i18n'' database. If the actual article doesn't exist, then the code checks if there is an ''i18n'' key of the same name and uses that if there is.
 
The "MediaWiki" namespace is a special namespace which is used to interface with the ''i18n'' database. If the actual article doesn't exist, then the code checks if there is an ''i18n'' key of the same name and uses that if there is.

Latest revision as of 03:32, 2 January 2011

A place to discuss the architecture of a multilingual wiki

nifty translation sites

sisterwiki structure:

  • en.host.com/wiki/page <-> pt.host.com/wiki/page
  • one-to-one correspondence among languages via subdomains
- requires administrator to create subdomain
+ symmetric and non-biased
+ subpage organization permitted
+ categories, templates, properties can be differentiated and translated
- categories, templates, properties must be duplicated, making administration potentially chaotic

vs.

subpage structure:

  • single domain using subpages: host.com/wiki/page <-> host.com/wiki/page/pt
  • dominated by English hub as default
+ does not require administrator to create language subdomains
- ugly structure with one language at top of hierarchy
- subpage organization not permitted
+ categories, templates, properties are unified into a single hierarchy
- categories, templates, properties become complicated to render in multiple languages, require alternate renderings and additional complexity, possibly many redirects that could introduce chaos into the wiki

vs.

middle path:

  • single domain using language parent directory: host.com/wiki/en/page <-> host.com/wiki/pt/pagina
could this be the best of both 1 and 2 above without their drawbacks?
- requires restructuring of existing English-only site to make structure completely congruent with other languages, otherwise, could be host.com/wiki/page <-> host.com/wiki/pt/pagina
This is actually not much different than the sister-wiki/sub-domain based way, since both require the same back-end changes - i.e. a new wiki created for each lang and filesystem changes to be made. --nad 14:28, 1 November 2010 (PDT)


Unless you're meaning that there is only one wiki involved here and that the language is encoded into the page title e.g. de/foo --nad 14:30, 1 November 2010 (PDT)
Yes, it's just something that popped into my head. Not necessarily a good or viable idea.--Infomaniac 11:28, 3 November 2010 (PDT)

i18n

Another thing to consider with multilingual wiki/CMS is the messages aspect. In our system we're providing a lot of templates and forms which include content that requires multiple languages. For this type of content, the i18n messages are the best place to maintain them so that they can be easily integrated with the translation community.

The "MediaWiki" namespace is a special namespace which is used to interface with the i18n database. If the actual article doesn't exist, then the code checks if there is an i18n key of the same name and uses that if there is.