User:Purodha/Suggestions for Wikis hosting several Dialects.

This is an incomplete draft, consider it work in progress and thus unstable, and possibly wrong. If you have proposals, suggestions, criticism, please leave them on the Talk page. Thank you.

---

How to deal with dialects and spellings in the Ripuarian Wikipedia.

A proposal by Purodha Blissenbach http://ksh.wikipedia.org/wiki/User:Purodha

1. Note: The terms "dialect" and "language" are used interchangeably within this document.
2. Note: Wording is intentionally general sometimes. This is to avoid even faint traces of linguicism, and to ease the adoption of this document for other language communities, should the desire exist.

General

What we have

1. We have several dialects in the Ripuarian group.
2. There exist several spelling systems for all of them, in addion, individual spelling systems my exist for a dialect.
3. Spelling of a dialect is very often not fixed even for a given spelling system, and may vary between authors or with certain aspects of the spoken language. Likewise, the spelling of individual words, or groups of words, may be altered according to certain speech patterns, and by types of sentences.
4. We usually have only (extended) Latin script. Very likely we shall have Rheinische Dokumenta later. Generally, we can use any script for which trabscription rules exist, currently none but Rheinische Dokumenta.
5. Many languages have an associated preferred or default spelling system, likewise has the combination of language plus script.
6. The user base, both readers and editors, is likely distributed unevenly between dialects an preferred writing systems. Populations are ranging from at best few hundred speakers of one to an estimated quarter of a million native speakers of another language. Understandability is much better, but also limited to some extent between distant languages, and even much more, spelling systems.

What we do

1. Unnegotiably, all lanuages and their variants, spelling systems, scripts, are to be treated equally and are to be supported equally well to the broadest extent technically possible. That means that, where possible,
   1. we accept editors contributions as they are and do not make any choices for editors, while at the same time
   2. offering a maximum of choices for readers letting them select and use their preferred dialect, or spelling, or script, when available, for reading and typing.
2. Attempts or propositions to specialcase any given language, spelling, or script above others are not made, nor discussed. Newcomers are educated accordingly.
3. Serious continous evangelism, missionary behaviour trying to promote a language, spelling, script, and linguicism are unacceptable.

• Minority support.

MediaWiki

Interface localisation

Given, we have editors doing the labour, we provide message interface localisations in every dialect and every spelling system and every script, that we can. When enough such data has been established, it is likely that the task of adding another edition can be semi-automatic.

Selecting localisations

Logged-in users, both readers and editors, can choose their Mediawiki interface language. Like some other languages do, we add an array of varieties of Ripuarian, including spelling system and script. While casual readers generally can select a language/group+dialect+spelling+script on the command line ("?uselang=ksh"), they cannot be expected to know about that, or use it, nor to log in. We shall deveolop a system allowing them to make, and revoke, their choices, too. This shall treat language, spelling system, and script separately, which offers added flexibility and is compliant with existing and developing ISO standards, and compatible with other software.

When either or all of dialectal variant, spelling system, or script cannot be determined from set user preferences, browser settings could be used as hints, but these are presently almost always useless for most of our wishes. That may, however, change in the future.

Users may have preferences that we cannot (presently) fullfill, and may have made no choices at all. For such cases decent defaults and fallbacks need to be established, usually choosing something which is deemed closest to the user preference. When there is no other possibility, we may want to resort to something "central" or "mainstream", which the broadest audience likely understands, or make some sort of random choice so as to implement equal treatment, a round-robin method, etc., or one or another combination therof.

Open question: how exatly should defaults and fallbacks be selected?

Note: for technical reasons, there need to be two implementations at least, one for users not logged in, and one for logged in ones. They can have different way of decisionmaking.

Searches

User should be able to use their language and their spelling in search boxes and find all information useful to them. Since Wikimedia searches are incapable of dealing with spelling variants, and have other limitations, that may mean expanding software with a better suited search. Meanwhile, the only way to archieve the goal are redirects. So we allow (and at least in the Article name space actively create) redirects mapping each and every dialect+spelling+script to the respective page. In cases of overlap, this makes additinal disambiguation pages necessary, luckily only few.

Articles

Articles are meant for readers. Technical background matters should be kept out of articles, at least not be visible unless one inspects the wikitext source of an article. Likewise, coordination, dispute etc. of the community of editor should not take place in articles. When readers should be made aware of such effords (e.g. 'can you determine/name this dialect?' or 'scheduled for deletion'), that should be done in a consistent and decent way.

Article titles

First editors choose article titles.

1. If an article title already exists with the same spelling, and that is or redirects to a disambiguation page, another choice shall be added to that page if needed, and the new page title needs to be more specific.
2. If an article, or a redirect to one, already exists under a choosen title, it needs to be renamed to something more specific, and the redirect created by the rename operation is edited into a disambiguation page, which is treated as described above.

Open question: How to name articles, if parallel ones exist in different dialects, following different spelling systems, or in another script? In addition, how to make a safe choice as to multilingual mediawiki transition? In addition, how can we make automated selections possible following user preferences before multilingual mediawiki is rolled out?

Open question: How exactly are article titles determined when there is conflict about them among editors?

Translations

It is perfectly well to have article titles translated in various dialects, or transcribed in other spelling systems, or scripts.

Identical content should be strictly kept together under one common page title, for the time being, until further software development lets us make more sound choices. Thus all but one of the varying spellings, according to dialect, spelling system, or skript, are redirects. This is expessly a temorary solution.

Article bodies

Editors choose freely which dialect, spelling, and script they wan to use.

Tagging

Editors are asked to mark their articles, or sections, as being written in an (un)specified dialect, spelling, and script. We provide templates for that. If they deviate, e.g. in citations, they are encouraged to tag the deviating words or sentences (e.g. ... , or same with the help of a template)

If a text consistency could not be maintained, or a specific dialect, or spelling system, (or script?) is unknown, and could not be determined, tagging can or should be with a "mixed Ripuarian" or "unknown Ripuarian" label.

Amendments

When making minor amendments, editors are asked to follow the surrounding style, dialect, spelling and script, if they can. Such amendmends should be reviewed and edited for consitency, if need be.

Major additions can be using another dialect, spelling, or script. If so, the section should be tagged appropriately.

Linking

Wikilinks shall be made using the dialect, spelling, script appropriate for their environment. It is up the author to use either of [[target variant|local variant]], or [[local variant]] with the latter being a redirect or not.

Translations

It is perfectly well to have article contents translated in various dialects, or transcribed in other spelling systems, or scripts.

Yet identical content should be strictly kept together under one common page title for now, so as to ease transition to new software versions.

Suggestion: For sufficiently short articles, translations, or transcripts, should be stored in one page, and only tagged apropriately, for the time being, until further software development lets us make more solid choices.

Suggestion: For sufficiently long articles, translations, or transcripts, should be stored in subpages denoting dialect, spelling system, and script in their subpage name, and tagged apropriately, for the time being, until further software development allows us make more solid choices. The main page to the subpages can either offer a list with a link to each subpage, or make and automated choice depending on user preferences an directly jump to one.

Suggestion: Small pages could also use the approach with subpages, and include them all, rather than listing, and linking, them, or branching to them.

Suggestion: If user preferences are missing or do not lead to a decision, main pages can be offering a coice to the user, the result of which can be recored so as to support futuer decisionmaking.

Templates

Despite of a variety of possible names, for the sake of maintainability, there should only be one template for any given purpose. More complex templates structures are made likely only by few technically inclined people. They shall be documented well, and should be easy to use

Template titles

As many redirects as needed should support editors so as not having to memorize title names and spellings strange to them.

Template contents

Templates should be maintainable, short, and structured. They should not contain documentation, but see section "Template talk page contents" in this document.

If a template needs to contain data, such as e.g. the names of all places in a region, all popes, or messages like "this page is under construction", it should collect all translations and transcripts in one place, and let another, common, template nested deeper down in a calling tree, decide which of them is actually shown. This promises to support a later transit to a dictionary based approach best.

Parameters

Template parameters being necessary at several places, but sharing a common meaning, should always be named and used identically. Whever possible, existing or planned standards should be followed when identifying entities. E.g. a script selection could be "script=Cxxx", where "Cxxx" is the ISO-15924 script code.

Template talk page contents

The initial section of a template talk page should describe the template use, its parameters, etc. at least, when it is intended for general use and it is not straightforward.

Categories

Category page content

To faciltate the later transit to a multilingual dictionary based category page naming system, category pages should be used to collect their names in various languages, spellings, and scripts already. Possibly, we can have the names shown already matching the readers selection of preferences, when we employ a conditional template to do so.

See also: section "Redirected Category Pages" in this document.

Project pages

Project page content

Basically, for help pages, pages documenting what we do, how we do it, etc. the same basic rules apply, as for the article name space.

Talk pages

Media pages

Uploaders are encouraged to make their contributios available on MediaWiki Commons rather than locally. For those uploads, rules exist.

Media page titles

Media page tiles are freely chosen by editors.

Media page content

Media page tiles is freely chosen by editors. The usual rules regarding copyright etc. apply.

Redirects

Where technically feasible, redirects are used so as to allow finding content under various names which may be available for one subject matter, such as an article, template, project page, etc. when all dialect, spelling, and script variants are collected.

Redirected page titles

An extensio to the mediawiki software is being planned and developed that shall allow the redirect and target page title display to be (optionally) inverted from the current fixed format, i.e.

Target Page Title
redirected from "Redirect Page Title"

 may become:

Redirect Page Title
this page is actually stored as: "Target Page Title"

if selected so in the MediaWiki name space. This makes it easier for readers to cope with the fact that actual page titles might not be using "their" language, script, or spelling.

Redirected Category Pages

A technical problem exists currently when attempting to redirect category pages. It basically does not work as naïvely expected. This is a temporary problem, however.

Plans and actual development work exist for the category system of MediaWiki Commons to make it dictinary based and truly multilingual. We shall likely be using the new system as well, as soon as it becomes available.

See also: section "Category page content" in this document.

Tagging

Script tagging

• → http://www.unicode.org/iso15924/iso15924-en.html

Despite the fact that, for the Ripuarian languages, there is currently no need for script variations - but may arise with Rheinische Dokumenta - when we do need to specify script, alpha-4 codes of the ISO-15924 standard are to be used.

To be on the safe side, templates should allow script to be specified at least in the sense that, neither including a script parameter in a template call at the outer level, nor omitting it, shall be deemed incorrect or create errors. At inner template levels, script parameter values most often need to be propagated one level down.

Other reading

• http://langcom.wikimedia.org/wiki/Language_proposal_policy/GerardM-Pathoschild

References

ISO-15924 — http://www.unicode.org/iso15924/iso15924-en.html