Most readers and editors should never have to think about translation patterns.  They should simply be seeing the languages they understand and not seeing languages they don’t unless specifically requested.  While they can create, read, update, and delete cards of any language, but everything should happen for them in their default language unless they choose otherwise.

 

So to begin, we have to know which languages the user understands / prefers.  We will have a first guess at this based on location.  But even passive users (those with no account) should easily be able to choose to view Wikirate in other languages. Language preferences setting will be stored in sessions for these cases.  By default, interface for setting language will feature prominently atop every page of a multilingual site, and it will likely follow the flag-based convention. A user with an account will be able to store language preferences more permanently.

 

Users can determine not just a preferred language, but an ordered list of preferred languages.  For example, a user who prefers German but would like to see English where there is no German available would express preferences as a list of two languages: German, then English.

 

For each language pattern, the handling is fairly obvious when either (a) content exists for a prefered language or (b) the card doesn’t exist at all.  When it exists, we show it!  When it doesn’t it acts largely like a missing card now (except with locale-specific messaging).

 

The tricky part is figuring out what happens when a card exists, but content doesn’t exist in the requested language.  

 

Universal

Not applicable.  By definition, if the card exists and follows the universal pattern, then the content exists.

 

Monolingual

In general, a request for a monolingual card will be treated as an “explicit” request for that language returned in the card’s original language.  As designed, this should not be a frequent occurrence.

 

Strict

This will depend somewhat on the view / context.  If the card is the main card on the page, we will probably want to (a) indicate that the card is not available in the current language, (b) offer the user the opportunity to translated it, and (c) offer automated assistance in the form of automated translation (hereafter we'll refer to this as "google translation" to avoid confusion with mapping, but we won't be tightly bound to Google.  Google Translation will only be used in this context – as an editor’s aid, not as a producer of final content for readers.

 

In other contexts we will want to show something much less obtrusive, but that leaves the opportunity to navigate to the interface described above.

 

Note that there will need to be analogous views for cards where the translation exists but may be out of date.

 

Free

Free cards will be similar to strict, but (a) the google translation is offered more as inspiration and may be discarded, and (b) there is no concern about out-of-date translations.

 

Mapped

In general, "mapped" content will be content containing translated names.  When those names are not translated, the handling will largely be governed by the patterns outlined for the type of the named card (see above).

 

 

Community Dynamics

 

For this approach to thrive on a community site like Wikirate.org, translation will have to become a central activity on the site. But on the positive side, it has the possibility of becoming a very enjoyable, low-barrier to entry activity. Those who are capable of translations (inferred from the knowledge of multiple languages) will be invited to engage in this activity.

 

Web addresses

 

Note that all web addresses will need to indicate the language requested, eg:

 

http://wikirate.org/en/Company

 

Note that the “en” here does not determine the language to be shown; it tells Wagn to interpret the word “Company” as an English word.  With this convention, if you have German preferences set, for example, Wagn will show you the German version of the Company card.   Without this convention, there is no handling of false cognates, and the same url may show unrelated cards to different people.

We can put together a strategy for handling old links to make sure this doesn’t lead to lots of broken links, but I think this change to the RESTful web API is needed