Wikisource:Scriptorium/Bug 32189
This discussion is transcluded from Wikisource:Scriptorium/Bug 32189 on wikisource.org aka sourceswiki aka multilingual wikisource (fka "old wikisource")
- Bugzilla:32189 is the bug requesting our interwiki languages links to be fixed so that subdomains can have correct sidebar links to works and other pages on this project. The bug, however, also touches on issues of whether mul.wikisource.org needs to exist. A discussion of this bug started on en.ws but I have moved it to a subpage on mul and transcluded this discussion on both mul and en.ws.
Bugzilla:32189 oldwikisource language id bug
[edit]I don't fully understand this issue...
Isn't http://www.wikisource.org suppose to be the multilingual portal(i.e www.wikiwhatever.org )?
The wikipedia family has one and the language code is correctly set to mul & which is overridden as needed by every other language that needs to be listed or linked on a per div or span basis. See
- See http://meta.wikimedia.org/wiki/Talk:Www.wikipedia.org_template for the basics.
... but we don't have the typical multilingual portal for the Wikisource family..
- See http://meta.wikimedia.org/wiki/Talk:Www.wikisource.org_template for leftovers.
...the WWW url redirects to the oldwikisource's Main Page instead because this Meta template is missing/invalid/dead.
The way I see it, creating mul.wikisource.org or mul:s won't solve the interwiki/interlanguage/translation issues - everything will still need to be hacked or scripted to function as some workaround, No?
I think we need to separate the missing mul/www-prefixed multilingual portal from the rest of oldwikisource proper and use one of the other two (special) ids for site/lang ID dedication (mis.wikisource.org or und.wikisource.org)
- {{language|mul}} → Multilingual
- {{language|mis}} → mis misc. - needs to be added
- {{language|und}} → und undefined - needs to be added
Not sure what happens to all the current pages based on English but all the other languages that are present will probably no longer need to override English via scripts/templates for starters. Am I missing some key fact or something here? -- George Orwell III (talk) 06:35, 13 April 2012 (UTC)
- I'm not sure but I think you may be right that multiple solutions are required here for distinct problems and that is contributing to some of the confusion on that bug. I will note though that this really needs to be discussed on wikisource.org. The problems I see are:
- Works that are in a language that has no subdomain (and may never have one for some very obscure or historical languages), works that are in a language that has a subdomain but the subdomain has a stricter copyright policy than US law, and possibly works that are truly multilingual (i.e. they have no base language) such as treaties, need a home. Currently they are maintained on wikisource.org.
- Interwiki language links to works noted in 1, above, should function the same as other interwiki language links that is
[[xxx:Some page]]should create a sidebar link to "Some page" on the appropriate wikisource. Currently, this fails with wikisource.org. This is the reason for the bug you reference, which was filed by Candalua. As noted by Candalua, the ISO 639-2 language code for multiple languages is "mul", so the link should ordinarily be styled[[mul:Some page]]irrespective of whether mul.wikisource.org is a subdomain. - Matters of general interest to all wikisourcerers (to use Dominic's term for us) need a place to be addressed; particularly development issues and documentation, as well as shared scripts. Currently that place is wikisource.org. If works and templates were removed from there, it probably wouldn't need linking except maybe from Scriptorium, which could be managed with my js workaround currently in use here. There is probably no good reason to keep this at the same location as works.
- Did I miss some things or misstate some things? Very likely. On a related note I'm going to be writing up a page on wikisource.org to discuss all of the many issues involved in any multilingual work, both technical and stylistic. The current system creates many problems. All known alternatives create other problems - though not necessarily of the same quality or quantity. Again, all of this should be discussed over at wikisource.org as we can't really resolve it here - though obviously this location gets more day-to-day traffic.--Doug.(talk • contribs) 11:13, 13 April 2012 (UTC)
- I'm not sure but I think you may be right that multiple solutions are required here for distinct problems and that is contributing to some of the confusion on that bug. I will note though that this really needs to be discussed on wikisource.org. The problems I see are:
- Points all well taken here & agree its complicated, but I don't see how you are accomplishing anything by applying the MUL id. If a work is in Russian, you are currently overriding the default HTML language designation (English - but not us here on en.WS English) and subsequent skin generated mw-content-ltr/rtl div class(es) for manually added Russian. Making the default language MUL still means you need to overide it to be able to get to editing in Russian (not phoney script hacked, font induced Russian over English). What you want is to override an undefined default - making your manually added language id and direction the default by fallback (hopefully).
- All MUL indicates is that multiple languages appear on one page - not multiple pages with differing languages for each page throughout a site. In short MUL is not meant to be a site wide default but a per page default (typically overridden by multiple div or spans with their own language ids as needed). UND, however, makes the user added language the Default for any particular page consistently site wide. Of course, The MW & WS namespaces among others will need to be overidden by English if a 1st fallback is unassignable at the skin level (the level where the HTML & BODY tags are actually assigned a language).
- Plus -- it is kind of unfair to usurp the standard multilingual portal for oldwikisource's main page. I understand feelings run deep and over a long time concerning oldwikisource but to pidgeon hole hundreds of thousands pages found in established language sub-domains for the sake of 10K on life-support seems counter-productive to put it mildly. -- George Orwell III (talk) 15:34, 13 April 2012 (UTC)
- Hmm, I need to think about this some. I'm really not stuck on "mul", just need something. If you don't object, I'd like to do something we don't normally do here and move this discussion to it's own subpage and transcluded it both here and at wikisource.org's Scriptorium. Probably the subpage should actually be over there. I'll make the move and you can revert if you strongly object.--Doug.(talk • contribs) 15:08, 15 April 2012 (UTC)
- You'd be the only one who can do that. Just noticed Mobile View (wayyyy down at the bottom of most pages) doesn't work on OldWikisource either. Look -- if we don't have enough traffic issues as it is -- I personally don't want to miss out on the mobile content revolution so I move resolving this sooner rather than later be a priority over most of the other "neat-o" editing bells & whistle Bugzillas if at all possible (and that www.wikisource.org multi-language portal page has to come back to the wiki-wide standard over the current redirect as OlsWikisource's mainpage. We don't want folks landing on sub-standard pages with sub-par transcriptions as part of our guiding principles so it only makes sense the same apply to (sub)domains that don't carry the same basic functionality as the other wiki foundation sites do. -- George Orwell III (talk) 22:18, 15 April 2012 (UTC)
- Mobile on multilingual is now Bugzilla:36002, thanks. :\ --Doug.(talk • contribs) 04:56, 16 April 2012 (UTC)
- Well, just to be clear, what I meant there was resolving the domain-name question as laid out in Bugzilla 32189 before addressing all the other bugs/wishes out there. If making "noise" on the mobile question gets us there faster; all the better. If they fix the mobile view issue without resolving the domain name questions; we might have made things more complicated in the long run. -- George Orwell III (talk) 10:42, 16 April 2012 (UTC)
- I agree, I tend to think it's best to list all bugs as we find them and we can always note that it depends on the other bug if we think that's the case or simply request that they defer the solution until the other matter is resolved.--Doug.(talk • contribs) 12:08, 16 April 2012 (UTC)
- With help from enomil, we have determined the problem is in the MobileFrontend, it's looking for a three-part domain name and can't handle a two-part domain name like http://wikisource.org--Doug.(talk • contribs) 08:25, 17 April 2012 (UTC)
- Well, just to be clear, what I meant there was resolving the domain-name question as laid out in Bugzilla 32189 before addressing all the other bugs/wishes out there. If making "noise" on the mobile question gets us there faster; all the better. If they fix the mobile view issue without resolving the domain name questions; we might have made things more complicated in the long run. -- George Orwell III (talk) 10:42, 16 April 2012 (UTC)
- Mobile on multilingual is now Bugzilla:36002, thanks. :\ --Doug.(talk • contribs) 04:56, 16 April 2012 (UTC)
- You'd be the only one who can do that. Just noticed Mobile View (wayyyy down at the bottom of most pages) doesn't work on OldWikisource either. Look -- if we don't have enough traffic issues as it is -- I personally don't want to miss out on the mobile content revolution so I move resolving this sooner rather than later be a priority over most of the other "neat-o" editing bells & whistle Bugzillas if at all possible (and that www.wikisource.org multi-language portal page has to come back to the wiki-wide standard over the current redirect as OlsWikisource's mainpage. We don't want folks landing on sub-standard pages with sub-par transcriptions as part of our guiding principles so it only makes sense the same apply to (sub)domains that don't carry the same basic functionality as the other wiki foundation sites do. -- George Orwell III (talk) 22:18, 15 April 2012 (UTC)
- Getting back to this, I don't see setting the interwiki language link to "mul" as requiring us to apply "mul" as its "site wide default" language. On the other hand, your point about the main page is well taken - we should have multiple language content based mainpages, especially if we concede that some languages may never have their own subdomain. Possibly, we should even have a content based mainpage with multilingual content, that is to say, it would display works in multiple languages and maybe work as a portal to the works on the subdomains rather than the current system, which seems to give more of a "For French go here" than a "For works in French go here" flavor; I truly hope the latter is what we want our main page to project.--Doug.(talk • contribs) 09:38, 20 April 2012 (UTC)
- The order of language determination goes → sitewide setting → sitewide fallback(s) → user preferences setting → user preferences fallback(s) → per page setting → per block(s) on a page (core JS, CSS and a handful of MediaWiki / Special pages are always in English). You can set whatever 2 or 3 letter domain name prefix you like as part of a recognized interwiki "id" as you like as long as the real language identifiers for site, user and page are set according to what outcomes are desired when clicked-in /clicked-on independently.
Life would be somewhat easier if the 2 or 3 letter domain name prefix "matched" at least the site id assignment but that betrays the desired outcome of a true single language environment for both editing and viewing. This is why I believe ( and stress believe only ) that in order to achieve the desired outcome in old wikisource's case, one where multiple languages will be hosted under one umbrella site domain name & not so much a site with a batch of individual multi-lingual pages, the best possible option is to have an undefined site id; letting the appropriate language fallbacks dictate where folks land and in what medium they will be able to view and/or edit any give page in.
What exists now is nothing more than a ["broken"] English language based site and folks are merely hacking it so that some other language overrides that default English language code when it comes to editing / viewing. So sure, using MUL will solve your cherished interwiki linking in the sidebar and such, but it won't mean the site is really multi-language capable nor truly MediaWiki interwiki / translation enabled. -- George Orwell III (talk) 14:49, 23 April 2012 (UTC)
- The order of language determination goes → sitewide setting → sitewide fallback(s) → user preferences setting → user preferences fallback(s) → per page setting → per block(s) on a page (core JS, CSS and a handful of MediaWiki / Special pages are always in English). You can set whatever 2 or 3 letter domain name prefix you like as part of a recognized interwiki "id" as you like as long as the real language identifiers for site, user and page are set according to what outcomes are desired when clicked-in /clicked-on independently.
- Hmm, I need to think about this some. I'm really not stuck on "mul", just need something. If you don't object, I'd like to do something we don't normally do here and move this discussion to it's own subpage and transcluded it both here and at wikisource.org's Scriptorium. Probably the subpage should actually be over there. I'll make the move and you can revert if you strongly object.--Doug.(talk • contribs) 15:08, 15 April 2012 (UTC)