User talk:Barto/Sandbox/mw

From ProofWiki
Jump to navigation Jump to search

Multiple languages

As I have some free time right now I'll leave a few comments. I'll write more later about other aspects.

We would have two options, in short, and that would be,

  • All the language versions under a single domain, possibly using the Translation Extension (the ext that the wmf uses for their wikis)
  • Creating subdomains for each language (en.proofwiki.org, de.proofwiki.org, zh.proofwiki.org etc.)

I would personally prefer the former

  • The website will, ultimately, remain united. The community will still control the policies of the site as a whole. Whereas, if it splits into numerous subdomains, each different language community will have different ideas of how to present proofs, different ideas regarding writing style, etc. Having a single domain avoids any such conflict on the original motivation of ProofWiki, particularly if they adopt some more laxed views.
  • Saves having a bunch of inactive subdomains. If an author comes along and decides they wish to translate a few articles into their native language, they can do so without needing to create a new subdomain which will ultimately be inactive. That said, ProofWiki would likely be subject to the Incubator, in which sites are developed as a "Test Wiki". Once this testwiki gains enough interest and enough contributors to justify a subdomain, one will be created, if we choose the latter.
  • The translation extension provides a friendly interface for translators. Depending on how it is implemented, knowledge of wikicode or MathJax will scarcely be required.

The disadvantages however,

  • Of the translation extension... I'm unsure of the practicality of using the translation extension for articles that are actively edited. I have only seen it used for help pages that remain mostly static. When a page is edited, a user with translation admin rights would have to mark it as "ready for translation". This obviously creates extra administrative work. Additionally it might be awkward to mark sections for translation. Basically, we would add a <translate> tag to the top of the article then add tags to denote "blocks" that will differ between the language versions, for translation. We will have to decide how these are implemented. Alternatively, we can just have subpages where different language versions are built without the use of this extension, avoiding such a complication. For content pages at least. As policy pages remain static most of the time I would suggest that the translation ext should still be used in these cases.

I will add to this as I have time.

Unrelated note: only one other site has been successfully adopted by the wmf, from what I know, and that is WikiVoyage. Might be worth checking out their proposal for inspiration. I haven't looked myself though. Caliburn (talk) 04:51, 13 November 2017 (EST)

I had the exact same ideas, in that I would prefer translation, the problem being that pages can rarely be considered finished. Additional thoughts:
-
  1. WMF (or we) will probably want to allow anyone to contribute, even if they hardly know English. See also 1 below. Translation partly takes care of this, but a problem arises (1) with discussions: requires more knowledge of English; (2) in the exceptional(?) case where someone has a new proof/definition but does not know English sufficiently. In either case, it seems we should encourage everyone to try writing in English, even when it means we'll have to correct many language-related mistakes.
+
  1. Mathematics, especially at PW, is relatively limited in terms of words and expressions, so that one does not need to know much English to translate something. For some Germanic languages, translation can be done almost word by word.
  2. Translating avoids duplicating work.
ProofWiki and Wiktionary seem to be most fit for direct translation. --barto (talk) (contribs) 12:09, 13 November 2017 (EST)
While the migration to the wmf will mean that anyone can create an account to contribute, we will still be able to restrict the abilities of new users. (I will expand upon this elsewhere) Furthermore just because anyone can technically contribute, that does not mean we have to accept contributions written in exceptionally poor English. There's a significant issue on non-English wmf projects where English speakers will machine translate from the English article to another language, resulting in several poor quality articles. These are deleted, and if the activity of said users becomes disruptive, this user will likely be blocked, with sufficient warning. (these warnings should really be written in their native language to ensure no loss of meaning) We can adopt a similar stance if a user decides to use machine translations or write in very poor English. It should be emphasised to the user that it is not out of malice, but rather to maintain the quality of the project. I suppose an advantage here would be having subdomains, where we could simply encourage users to contribute to their respective language version, until they improve their English. That said, ProofWiki differs substantially from Wikipedia in that, for most proofs, there isn't a great amount of prose, (though Wiktionary pretty much has none) meaning that any issues with poor English, or machine translations, can be resolved relatively smoothly. My problem is therefore chiefly with more "wordy" (often means more mathematically technical) proofs and definitions. In both cases, clarity is often key. You are correct with the second point. In some cases translators would be able to translate competently without relevant subject knowledge or much knowledge of English, while I'm a bit unsure as to whether that should be encouraged. Though, English and German are reasonably similar anyway. Our problems will come with languages less related with English. Have some more free time now so I'll see what else I can add. Caliburn (talk) 14:01, 13 November 2017 (EST)

Restrictions on new users

In my opinion due to the relative complexity of this wiki's mos and policies, it might be best to initially restrict the editing abilities of new users, primarily as we would lose all control over creation of new accounts. A nice solution would be going the way of Wikibooks/the German Wikipedia. Initially, all edits by a user have to be manually reviewed by users with the editor bit. Any unapproved edits are not displayed by default. This right is automatically assigned after a list of conditions, that can be discussed, are fulfilled, or assigned manually by an administrator. The editor bit can be assigned any flags that the community sees fit, including rollback, etc. The advantage of this is obvious, we can ensure that an editor's first edits are in line with policy and the wiki's MOS, guiding them appropriately on their talk page should they make serious errors. On the downside, this requires an active editor-base to remain viable, (else the review queue may either become severely backlogged with garbage, as is largely the case with the English Wikibooks, or completely empty) something we can't really gauge until the transition is complete. Alternatively, we can remove the ability for the editor right to be assigned automatically, and have it as a right only given manually by administrators. Though, we should set the conditions reasonably so that the editor right is not granted to inexperienced editors, somewhat eliminating a need for this solution. This could be added to the proposal, easily justified. Caliburn (talk) 08:45, 15 November 2017 (EST)