Latest comment: 18 years ago4 comments1 person in discussion
This sounds like something that probably should be built into the software. I just have a few notes about the implementation.
Almost all HTML tags have the lang attribute. This attribute is used like (quoted straight from the W3C specification)...
<P><Q lang="en">Her super-powers were the result of γ-radiation,</Q> he explained.</P>
CSS also provides facilities for creating attribute selectors for this sort of text:
span[lang=fr] {display:inline;} /* French */
At first glance, this would seem like a wonderful way to use appropriate markup, unfortunantely, certain browsers (like, ahem, Internet Explorer), don't support this sort of text. But, we can use JavaScript to do the same thing transparently when attribute selectors aren't available.
I don't know if it's worth doing it this way, but in browsers that support it (i.e. Firefox) it's pretty darn cool. Example:
<html>
<head>
<style>
.multilingual {display:none;}
.multilingual *[lang=fr] {display:inline;} /* French */
</style>
</head>
<body>
<div class="multilingual">
<div lang="en">He is good.</div>
<div lang="fr">Il est bon.</div>
</div>
</body>
</html>
It's an interesting method, but the CSS classes enjoy much wider browser support without javascript. When there's greater support for it, this would definitely be the preferred method. // Pathoschild (talk) 22:43, 28 March 2006 (UTC)
So, I'm thinking... why not use BOTH? Or have the wiki do it for us? :-O (probably technically infeasible, but hey, if we integrate this into user preferences, why not go the whole two miles?) Also, I think that any browser with CSS support should have some sort of JavaScript support, and the JS solution would mostly cater to the Internet Explorer crowd, most of whom wouldn't bother turning of JavaScript. But really, it's all about whether or not this contextual correctness is worth going the extra mile. Ambush Commander01:34, 29 March 2006 (UTC)Reply
The CSS classes are supported almost universally, excluding very old or very basic browsers. This method is stable and enjoys wide cross-browser and cross-platform support. On the other hand, a respectable number of users regularly disable Javascript, support flunctuates across browser and platform, and results are variable. The CSS method is fully standard and correct; although the lang attribute would be more syntactically correct, using Javascript to force compatibility isn't. In this case, applying Occam's Razor favours the CSS method. // Pathoschild (talk) 05:22, 29 March 2006 (UTC)
Latest comment: 18 years ago2 comments1 person in discussion
Usually, it's lowercase. Why are we putting the language codes in uppercase? Also, I think that the shorter lang- would be preferable. Just friendly suggestions. Ambush Commander01:36, 29 March 2006 (UTC)Reply
The language codes are uppercase in the original specification, but lowercase in Wikipedia's list of codes. Since Wikipedia already uses lowercase, I'm fine if we use that form. The two-letter codes are preferable, but not all languages have one; in some cases, we need to use the three-letter code. // Pathoschild (talk) 05:13, 29 March 2006 (UTC)
I meant class="lang-en", etc, instead of spelling out language. Lang is pretty much synonymous with language, and it's shorter to type.
Regarding the casing of the language codes, I noted that the three-letter ones were lowercase. Let's be consistent. One or the other. Personally, I prefer lowercase. Ambush Commander05:23, 29 March 2006 (UTC)Reply
Both lowercase and the shortened 'lang' are fine by me. // Pathoschild (talk) 05:54, 29 March 2006 (UTC)
Latest comment: 18 years ago3 comments1 person in discussion
I don't think a logo is really that necessary. First of all, in order to make it link to this page, you'd have to go through several circles of hell and some really ugly hacks (or get it done on a developer's level) I don't think redirecting the image page is a good idea. It makes it harder to view image info. Second, the current proposals are way too big to fit on the right side of the page.
I think the proposed logos are relatively universal. My favourite proposal (er, mine) is being used as the placeholder logo. This logo depicts three different alphabets stacked atop one another, with an arrow to a single centered alphabet. Since the most common languages on Meta use the Latin alphabet, it is depicted as the 'selected' alphabet. There is no need for it to be used in its original size; as a scalable vector graphic, it can be dynamically resized infinitely either way. For example, this size would easily allow it to be placed in the top right corner of a page (à la Wikipedia featured article) or in the corner of a template. However, the type should be enlarged to make it easier to see at that size:
Using images to link to a page is relatively common; the redirect is simplest, but an alternative method uses CSS to superimpose a link over the image. This method (from w:Template:titled-click) could be adapted to the purpose:
Yeah, the CSS based trick is a hack. I believe I've heard the developers discouraging its use, because it obscures the copyright info/image page of the image. Maybe a picture is in order. Ambush Commander13:05, 29 March 2006 (UTC)Reply
"Globe of letters"
I've sketched some other possibilities for logos. Once I get around to vectorizing them I'll show them. One interesting way of varying it is, instead of using different alphabets, using different two-letter language codes. Also, there are existing icons that could be used. Ambush Commander05:09, 30 March 2006 (UTC)Reply
I like that logo; feel free to suggest a few images, and we can probably decide on one without the time and effort of voting. // Pathoschild (talk) 01:18, 1 April 2006 (UTC)
Latest comment: 18 years ago6 comments1 person in discussion
With JavaScript, you can... gasp... automatically determine the language of the browser! Something like...
function startup(){
if (navigator.userLanguage) var language = navigator.userLanguage // use the user's preferred language (non-Gecko)
else if (navigator.appName == 'Netscape') var language = navigator.language // use the only language information available to Gecko
else var language = navigator.browserLanguage // get the browser language information in non-Gecko browsers (IE, Opera, Konqueror)
// Try to automatically detect the navigator's language, or else default to English
if (language.indexOf('en') > -1) displaySubs('en');
else if (language.indexOf('fr') > -1) displaySubs('fr');
else if (language.indexOf('de') > -1) displaySubs('de');
else if (language.indexOf('ja') > -1) displaySubs('ja');
else if (language.indexOf('zh') > -1) displaySubs('zh');
else if (language.indexOf('es') > -1) displaySubs('es');
else if (language.indexOf('pl') > -1) displaySubs('pl');
else if (language.indexOf('it') > -1) displaySubs('it');
else if (language.indexOf('sv') > -1) displaySubs('sv');
else if (language.indexOf('nl') > -1) displaySubs('nl');
else if (language.indexOf('pt') > -1) displaySubs('pt');
else displaySubs('en');
}
And then for those users who don't have JavaScript, we can always leave the lang selector style for them. And even further we can leave in the classes. Ambush Commander05:26, 29 March 2006 (UTC)Reply
This method might work, but I'm wary of setting this by default. Some users are multilingual; for example, I'd like to see the French version of a text as well. This method is completely transparent, so the user doesn't even know other versions are being hidden from them. This is a promising method despite my reservations, but I'd like more input to iron out the details and resolve any concerns. // Pathoschild (talk) 05:52, 29 March 2006 (UTC)
The transparency problem could be solved by an automatically added JavaScript link that says (show all languages). We could also get the JavaScript to write a cookie, if a user decides that they'd rather have a language different from their browser/display all languages. For logged-in users, we can offer a quick hook in javascript code to put in Monobook.js, either to turn it off, or use a different selection of languages.
A cool feature would be if the JavaScript notified the user that there was no message in the language they had as default, and asked them to help by translating the language to there. JavaScript makes that relatively easy to do. Ambush Commander13:03, 29 March 2006 (UTC)Reply
It's definitely an interesting path to take, if we have some users willing to code it. // Pathoschild (talk) 23:22, 29 March 2006 (UTC)
(points to self). Of course, I won't be able to actually implement it, since I'm not admin on this wiki, but I can spearhead the initial development. Ambush Commander04:20, 30 March 2006 (UTC)Reply
Great; I can give you admin access to a test wiki for development, if you need it. // Pathoschild (talk) 04:55, 30 March 2006 (UTC)
Okay, here's a proof of concept. Note that the lang attribute is absolutely necessary for this to work.
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title>Multilingual page</title>
<style type="text/css">
.multilingual {border:2px solid #A3B0BF;padding:1em;margin:1em;}
.foreign_language {display:none;}
/* .multilingual * {display:none;} language neutral */
/* .multilingual *[lang=fr] {display:inline;} French */
</style>
<script type="text/javascript" defer="defer">
//global functions
if (!window.Node) {
var Node = {
ELEMENT_NODE : 1,
ATTRIBUTE_NODE: 2,
TEXT_NODE: 3,
COMMENT_NODE: 8,
DOCUMENT_NODE: 9,
DOCUMENT_FRAGMENT_NODE: 11
}
}
function getLanguage() {
var language;
// find the language
if (navigator.userLanguage) {
// use the user's preferred language (non-Gecko)
language = navigator.userLanguage;
} else if (navigator.appName == 'Netscape') {
// use the only language information available to Gecko
language = navigator.language;
} else {
// get the browser language information in non-Gecko browsers
// (IE, Opera, Konqueror)
language = navigator.browserLanguage;
}
// remove dialect/region code, leaving only the ISO 639 code
var length;
if ((length = language.indexOf('-')) !== -1) {
language = language.substr(0, length);
}
return language;
}
function getAllMultilingualElements(n) {
var elements = new Array();
if (n.className && n.className.indexOf('multilingual') != -1) {
elements = elements.concat(n);
}
var children = n.childNodes;
for(var i=0; i < children.length; i++) {
if (children[i].nodeType !== Node.ELEMENT_NODE) continue;
elements = elements.concat(getAllMultilingualElements(children[i]));
}
return elements;
}
/* I'd like to use this, but IE doesn't support it!
var body = document.getElementsByTagName('body')[0];
var iterator = document.createTreeWalker(
body,
NodeFilter.SHOW_ELEMENT,
function(n) {
// doesn't make sure that the multilingual is by self, maybe bug
if (n.className.indexOf('multilingual') !== -1) {
return NodeFilter.FILTER_ACCEPT;
} else {
return NodeFilter.FILTER_SKIP;
}
},
false);
*/
// debug functions
function start_js_console() {
var js_console = document.createElement('textarea');
js_console.cols = 80;
js_console.rows = 6;
js_console.id = 'js_console';
var body = document.getElementsByTagName('body')[0];
body.appendChild(js_console);
}
function echo(string) {
var console = document.getElementById('js_console');
if(!console) return;
console.value += string + "\n";
}
// actual body
function main() {
start_js_console();
var language = getLanguage();
echo('Language is: ' + language);
var body = document.getElementsByTagName('body')[0];
// mls = *M*ulti*L*ingual*S*
var mls = getAllMultilingualElements(body);
var n;
for (var i = 0; i < mls.length; i++) {
for (var j = 0; j < mls[i].childNodes.length; j++) {
n = mls[i].childNodes[j];
if (n.nodeType != Node.ELEMENT_NODE) continue;
if (n.lang.indexOf(language) == 0) continue;
n.style.display = 'none';
}
}
}
setTimeout(main, 0);
</script>
</head>
<body>
<div class="multilingual">
<div class="lang-en" lang="en">He is good.</div>
<div class="lang-fr" lang="fr">Il est bon.</div>
</div>
<div class="multilingual">
<div class="lang-en" lang="en">I would like some water.</div>
<div class="lang-fr" lang="fr">Je voudrais d'eau.</div>
</div>
</body>
</html>
Another update! I've gotten a preliminary version of this script to work inside MediaWiki (after a killing a few bugs, mostly a problem with onloads). We need an admin. Ambush Commander01:21, 1 April 2006 (UTC)Reply
Latest comment: 15 years ago5 comments3 people in discussion
Maybe add xml:lang="en-GB" to lang="en-GB" (example), it's the recommended way to handle this in "XHTML transitional". The successor of RFC 3066 (approved but still waiting for its number) created a
IANA language subtag registry, nothing special there, but it offers all relevant info now also including scripts in one place. -- Omniplex(w:t)05:50, 3 May 2006 (UTC)Reply
it is now RFC 5646 (along with RFC 5645, and RFC 4647 which did not need a change for this standard track).
The IANA language subtag registry was last updated on July 29, 2009, to include all the tags from the latest versions if ISO 639-3, ISO 639-5 (language collections, more or less like language families, but they are now inclusive, instead of being exclusive in ISO 639-1 and ISO 639-2), and also ISO 15924 (scripts), and a part of UN M.49 (only those numeric codes for transnational groups of countries and continents). It also deprecated some codes (that are still valid anyway and maintained as aliases or special groups of languages (known as "macro-languages", as defined in ISO 639-3 and whose classification is also incorporated in the IANA registry), and fixed rules for correctly handling the script and variant subtags (when they can be safely discarded or assumed, making the combination language-script into aliases of the shorter language tag).
The correct reference to these RFCs, when they are updated by newer versions, is BCP 47 (which is the standard track under which the current RFC's chosen as the Best Current Practice is followed). Note that the W3.org standards (HTML, CSS, XML, XHTML, SVG...) are explicitly bound to BCP 47, not to a specific version of a RFC (and the same is true now for all IETF standards which uses BCP 47 as the normative reference, rather than ISO standards which are designed for other purposes, but did not maintain the principles of long-term code stability). verdy_p11:30, 30 October 2009 (UTC)Reply
Latest comment: 18 years ago2 comments2 people in discussion
Well, it's not like there no solution which doesn't need Javascript (there're still users out there who don't have it or don't want it ). With php, it'd look something along the lines of the following. --85.220.132.239 21:25, 10 June 2006 (UTC)-85.220.132.23921:25, 10 June 2006 (UTC)Reply
$browserLanguage = $_SERVER['HTTP_ACCEPT_LANGUAGE'];
// determine language, default: en
if(!$_SESSION['lang'])
$_SESSION['lang'] = in_array($browserLanguage,$browserLanguages)?$browserLanguage:'en';
// manual selection
if($_GET['lang'] && in_array($_GET['lang'],$browserLanguages))
$_SESSION['lang'] = $_GET['lang'];
etc. pp.
The problem with this method is that it totally breaks caching. Wikimedia relies on Squid caches to reply to most of the anonymous page request (which is what precisely what the JavaScript solution is targeted for).
Other problem: PHP solution hasn't been implemented yet (while JavaScript is live). Besides, in the end, it's just an extra feature to make user's lives easier. If they don't want it, it's not that big of a loss. — Ambush Commander(Talk)02:41, 11 June 2006 (UTC)Reply
Hmmm... the JavaScript solution (which has been enabled globally) may be colliding with the CSS solution. Try adding ls_enable = false; to your monobook.js, OR try removing the CSS and checking out the JavaScript version. — Ambush Commander(Talk)19:30, 12 June 2006 (UTC)Reply
Ok, now does it work by removing it. Now I see the javascript version. Or is it that this function does not work with IE? Now I use FireFox, before today IE. --Walter21:42, 12 June 2006 (UTC)Reply
Latest comment: 18 years ago4 comments3 people in discussion
This is interesting. Some initial thoughts:
it's better to use {{#language:XX}} rather than the language code "XX" (OK, on meta it doesn't matter so much, but not everyone knows what language codes are, even for their own language)
it would be better to have a drop-down list of available translations rather than just "type and hope" your translation exists
where is the actual code for that little box?? I can't find it
At Commons we tend not to have multiple languages on one page, but make heavy use of templates. See for example template:welcome which has Template:Welcome/lang (links to all translations) at the top of each translation. We are working as if template translation will one day work the same way MediaWiki namespace translation does (ie, if user has language set to XX, and MediaWiki:Foo/XX exists, it will display that, otherwise default falls through and it will display MediaWiki:Foo. We want that same behaviour for templates.
The other problem (again, not so much at meta) is for anonymous users. We would like to either auto-detect their language settings from their browser (see bugzilla:3665) or else have a drop-down language setting menu that stayed with them for that viewing session. At the moment even if they click a French translation the interface will stay in English. It is possible to work-around this by using uselang= links but this is not really scalable for the dozens of pages and doubtless thousands of links those pages have.
But yeah, interesting. We are very interested in improving multilinguality. Please leave a note on any of my talk pages if there are any interesting new ideas about this. --pfctdayelise02:55, 13 June 2006 (UTC)Reply
Is there a specific reason, why this solution doesn't use templates? <div class="lang-en" lang="en">This text is English.</div> is a bit difficult to type, something like {{en|This text is English.}} (as it is on Commons Commons:Template:en) would be easier to remember. --::Slomox::><12:48, 13 June 2006 (UTC)Reply
Okay. A number of things to answer.
The code is implemented in JavaScript and is located in MediaWiki:Monobook.js (I would have placed it in Common.js but that doesn't seem to exist). I will update the main page so this is more evident.
Regarding {{#language}}, I was not aware of this feature. I'll look into converting the current ones to this system.
Regarding a drop-down list, the idea is that you don't have to select your language each-and-every time. In a way, the widget is simply convenience, a quick way to change languages on-the-spot. It does have some deficiencies, I'll give you that. Perhaps something like that could be integrated into a "temporary-view", where you'd select the language in the case that your primary language didn't exist (but that would seem unnecessary if every single language is being output). This feature definitely needs refinement.
Regarding Template:name/lang, that would sound like a very neat feature, albeit slightly difficult to implement. The way that would work here would be there would be a "super-template" with all the languages transcluded, but then the JS would hide all but the relevant one (so a bit more text would have to be transferred).
Autodetection would multiply the amount of caching necessary to keep up our current framework. JS autodetection works nicely because all the possible translations are sent out, and then the user's browser picks the most appropriate one. Once again, not really appropriate for user interface.
Regarding templates, we don't use templates because I couldn't be bothered to make templates for all the different languages out there. ^_^" I can see how it would be useful though.
Regarding talk page, I'd rather keep this discussion in the mainspace. I can leave a note on your talk page though.
Latest comment: 18 years ago12 comments2 people in discussion
What's the story behind this construct? It's not obvious for me why class="lang-xx" isn't good enough as fallback. As always curious: -- Omniplex(w:t)18:50, 14 June 2006 (UTC)Reply
It makes the JavaScript a lot easier. Without a parent container marked multilingual, the JavaScript would have to traverse the entire document. Also, we'd have no place to put the language select widget!
The class="lang-xx" has a somewhat different use, it's only there to support legacy browsers that don't support attribute CSS selectors implementing the CSS trick. We could very well get rid of it and obsolete style-sheets (they weren't my idea). — Ambush Commander(Talk)19:38, 14 June 2006 (UTC)Reply
My browser certainly doesn't support CSS, but I'd consider anybody with enabled JavaScript as suicidal - of course making exceptions for MediaWiki sites is an idea. ;-)
If "language select" also works with <span> it should be now active in the "other languages" line of most help pages. No chance to use <div>s there, sorry. -- Omniplex(w:t)19:55, 14 June 2006 (UTC)Reply
I use NoScript, so JavaScript is disabled by default for me. However, 1) yes, I have whitelisted the MediaWiki sites and 2) no, I don't think a lot of people disable JavaScript. I've updated the CSS code to ensure that it works with inline elements too. I don't think we really should let people use anything other than divs or spans though.
There's a slight, unrelated problem to the other languages line: there is no clear differentiation between each link, instead, they're all strung together. A no-no in terms of accessibility. — Ambush Commander(Talk)20:15, 14 June 2006 (UTC)Reply
But if "multilingual" starts with default "hidden" the last +/- edit-link would be invisible, is there a way to break out of invisibility? All "ill"-s (inter language links) plus the +/- edit-link are within the multilingual-span, almost impossible to change this manually, see Special:Prefixindex/Template:H-langs:_. If you have a bot for this task I've another proposal how to fix the "ill"-s (good name). -- Omniplex(w:t)20:32, 14 June 2006 (UTC)Reply
According to most web accessibility guidelines, a space isn't enough. Ideally, we should be using a LIST, but MediaWiki makes that very difficult to do.
As for invisibility, I could always add an extra style to the global CSS to make sure it doesn't get hidden (note that the JavaScript doesn't have this problem), but I'm still not convinced that language selection should be used at all on the language selects.
I've never heard of this "space isn't good enough" guideline, is it W3C/WAI? I've a better idea how to solve the container problem, doing it in H:f Help wasn't the best solution, I'll fix it. -- Omniplex(w:t)21:55, 14 June 2006 (UTC)Reply
W3C. It's quite a pain sometimes in the world of wikilinks, but in this case, there's no reason not to do this.
That's why there is a separate Help page footer templates page explaining how stuff works in addition to the overall WM:HELP. No section headers in / on templates, it's confusing like hell. There's an edit link for this template on all help pages, folks are supposed to do the obvious thing, edit it as is. The H-langs line has its own +/- edit link. Folks are not supposed to edit the line including a specific H-langs, it clearly says so.
For the class="multilingual", can this come together (same tag) with the first language, establishing a default for anything contained in it? -- Omniplex(w:t)22:27, 14 June 2006 (UTC)Reply
That establishes a strong case for not placing documentation before the template body, but I'm still not convinced. If they click the edit link, they directly see the template area to edit. For things like {{H:f}}, it's not really meant to be edited.
Normally I use one of the documentation styles explained on Template documentation. If it gets out of hand needing sections and a ToC it deserves its own place on the talk page, e.g. Template:YMD2MJD has a mini docu on its page, and a test suite and what else on its talk page. For the obscure help templates the inventor created separate help pages if you really want to know the details caused by Meta's weird multi help namespaces. Normal editors just wishing to modify a language link or help page footer item never need this. A kind of OO templates maybe, talking about implementation details at the wrong / multiple places can be a bad thing.
The second question iswas - you've already disabled it in {{ill}}: Is it in theory possible to have
<div class="multilingual" class="lang-ru" lang="ru"> for a multilingual section with default Russian?
Thanks for the W3C link, I knew the checkpoint, it convinced me to change "all" (60) my pages, but I forgot the detail printable, not just anything. A monospaced <tt>|</tt> is sometimes nice, but not good enough for a break opportunity between links working with "any" browser. -- Omniplex(w:t)23:20, 14 June 2006 (UTC)Reply
P.S.: Multiple classes are not enumerated by multiple class attributes, that should be comma and/or blank separated (?). But my question is about the concept of a default language.
If it's about languages where you're sure that you cant display their name. let alone read any page in this language, it could make sense to hide the name. But as we've seen this widget thingy isn't designed to operate on single words / quotes, it wants a set of paragraphs in different languages, so that point is moot now. Maybe document that it's not meant to be used for all lang="xx" constructs. With that limitation better stay away from inline elements, maybe support more block level elements llike <p>. -- Omniplex(w:t)00:35, 15 June 2006 (UTC)Reply
P is not supported simply because MediaWiki doesn't allow it (don't ask me). Also, the widget thing CAN work on single words, but the whole kaboodle itself must be a block. This means that you can't have a word mid-sentence that can morph between languages, but you can have a multilingual block that, when displaying all possible languages, doesn't start a new line with each language.
The reason why I think language select on language select is redundant is because all the JavaScript does is make the page a little bit neater. It is by no means mandated or omniscient (it can and will make mistakes). When you have a list of links to other versions of the article, it's already fairly small and out of the way, so hiding them is of minimal benefit. — Ambush Commander(Talk)01:16, 15 June 2006 (UTC)Reply
Latest comment: 18 years ago3 comments2 people in discussion
As of now, the JavaScript solution can only take one language. What if a French American would like French, then English, and then finally show all the messages? Stuff of this complexity could only be accomplished with an advanced widget UI and a rule-based system.
What about displaying multiple languages? We could make the text box accept multiple language codes, but this could quickly get unwieldy, and also makes it difficult for the user to revert back to his preferred settings if he wishes to show all.
Which poses another question: should "show all" be sticky? If we make it un-sticky, how should we go about telling users that the language code for multiple languages is "mul"?
And... finally... how the heck are foreign users going to know how to use the UI if it's in English? Somewhat a chicken-egg problem, but also, translating the interface may be quite unwieldy.
Try and find a way to use diagrams and symbols in the UI - no text. Link a "???" symbol to a help page that has multilingual explanations. pfctdayelise03:42, 15 June 2006 (UTC)Reply
I don't like using symbols because unless they're extremely standardized, you run the risk of confusing everybody. Question mark does fairly well in this respect (even though it's a semicolon in greek).
However, relatively speaking, the question mark is the least of our problems. How do we represent concepts like "Save" and "Show all"? And using actual pictures can greatly increase the weight of a page. More little objects to load.
Latest comment: 18 years ago6 comments2 people in discussion
I really think this needs a drop-down box for language selection. To me it makes no sense to expect the user to type in their language code (assuming they even know what it is?!) especially when their translation may not even exist.
If we could do this then we would be able to implement this on commons:Template:information which is used on a large number of image pages.
The reason why language selection is done by text input is because it's meant to be global, so you type in and forget about it (except when you see a few messages that aren't localized for your language).
Also, a drop-down list might have slight difficulties in giving the names of the languages besides just the language code, because I'm not sure where one would retrieve this information from. Grabbing it from the internal message text requires a bit of parsing and is iffy in that it isn't guaranteed to exist. And I'm not of any JavaScript API that offers the translations. Calling #lang is intrinsic to MediaWiki and calling it via AJAX is not feasible.
I don't understand why typing in a code is "global" and yet picking your language from a list and hitting a button cannot be... also I don't know if this helps but English can be subst'ed. pfctdayelise11:43, 25 June 2006 (UTC)Reply
(sorry for the long wait, I was away in China, where Wikipedia is blocked)
Say we have a localized message that contains en and fr text. You speak de. With a drop-down box, only en and fr would be selectable, and you'd be left wondering, "Hmm... I want de!"
Whereas at the moment, you would type in "de" (assuming you, possibly the casual user, even know what that means) and you get everything but. Is that really a better solution? They seem about equivalent to me (when it comes to missing translations at least). pfctdayelise11:23, 13 July 2006 (UTC)Reply
The trouble with content negotiation is that it complicates Squid caching for a minimal benefit. Only a small amount of pages use this feature, and usually the feature is used on small sections of these pages. Content-negotiation is primarily meant to be used for entire webpages, so it would be adding a bit of overhead for a sentence or two that was multilingual.
Furthermore, the content is not relying on CSS/JavaScript: it degrades quite nicely when JavaScript is not available. Well, it is subjective (a giant list of translated strings may not be the most readable thing in the world), but compared with the alternative (only one language) it certainly is more accessible. — Edward Z. Yang(Talk)19:51, 2 September 2006 (UTC)Reply
I guess Pfctdayelise means that on Commons there are a lot pages which are mostly muntilingual. For example image descriptions and all our message templates for users etc. -Samulili16:58, 15 September 2006 (UTC)Reply
Does that mean that if a page is made up of multiple multilingual sections, each of them has a different drop-down list? And also, would a selection in one drop down list influence the other multilingual sections (both on that page and in future visits?) Also, would only showing iso-codes be acceptable, or is it that we absolutely must have fully qualified language names?
I'm just trying to get a handle on what precisely this would entail before I dive into any coding frenzy. I'm still not sure I precisely understand. — Edward Z. Yang(Talk)22:56, 3 October 2006 (UTC)Reply
The way it is handled on WiktionaryZ (see here for instance) is quite nice : a drop-down list where choices narrow as you type the name of your language. But making it simpler would also do the job : just a basic drop-down lost with iso-codes and (optionnally) the full name of the language next to it. I personnaly reckon that one selection box per page is better, even if not all the fields are translated : the reader will see anyway that the particular text is not available in <whatever language>. And the selection should be remembered for the rest of the visit, yes. Right, that was my wishlist ! Thanks, le Korriganbla09:00, 7 November 2006 (UTC)Reply
Latest comment: 17 years ago4 comments2 people in discussion
On every page the javascript variable wgUserLanguage is set to the languagecode from the preferences. Why not use that to select the standard language instead of the browser language. A lot of people are using an English browser, however it is not their native language. JePe23:37, 8 December 2006 (UTC)Reply An anonymous user cannot change his preferences, in that case wgUserLanguage is always set to the content-language (wgContentLanguage). To check that, the variable wgUserName has the value null in case of an anonymous user. So, if wgUserName has the value null: use the browser-language, if it isn't null: use wgUserLanguage to determine the language of the user. JePe11:40, 10 December 2006 (UTC)Reply
Latest comment: 16 years ago2 comments2 people in discussion
Hey,
We've had requests for the selector box to be potentially placed at the top of the page. Would it be possible to pass a JS option to the code to request it to render at the top of the page?
Maybe. The selector box has the class lang_info, so applying some CSS to that might do the trick. (The next problem, then, is to make sure that we don't display multiple selector boxes.) — Edward Z. Yang(Talk)00:03, 10 February 2008 (UTC)Reply
It would be better to change the script so that we always have only have one language selector box at the top of the page. If nobody else does it, I'll do it in a couple of weeks (I'm too busy right now). —{admin} Pathoschild 00:15:18, 10 February 2008 (UTC)
I'm just starting to teach myself how this stuff is written, so this may be a stupid question, but bare with me. Does divclass=multilingual have any parameters, like changing the position of the language selection? I've seen other divclass=XX that allow optional parameters to be added to it, but I can't find anywhere on the web that lists all of the possible divclass=XX and their possible parameters. Thank you.
Latest comment: 16 years ago1 comment1 person in discussion
Does this script support warning "needs updating" by appending FUZZY? It will be useful for multilingual text needs updating frequently(For example, 2008-09 Steward election schedule was changed so updating is needed).--Kwj277213:25, 5 December 2008 (UTC)Reply
Is this historical? Varnent thinks so. I think it should not be marked "historical" since it is still used widely. Maybe we should add a note about deprecation though. PiRSquared17 (talk) 23:50, 3 May 2014 (UTC)Reply
I would be fine with that. Mostly concerned with people attempting a new setup with this instead of translate extension. Although personally I wouldn't mind seeing the remaining places it is used phased out. --Varnent (talk)(COI)00:15, 4 May 2014 (UTC)Reply
For some time, LangSwitch is still definitely better than LangSelect which remains only on very few very old pages. I have maintained a few months ago LangSwitch to include many more languages. But it is still an interim solution before using the Translate extension which requires more preparation work.
For example LangSwitch is used on the home page, and I have still not thought converting it to the translate extension. This could be done but there are issues with many existing translations that do not match the current modelisation in many templates. Such work would require many small edits and microtransfers, as well as work to compare what exists and merge what would be useful to keep for everyone.
Anyway our local version of LangSwitch is definitely better than what was found in other wikis where it has not been maintained.
Yes LangSwitch could be more efficient using a Lua module, but as more and more pages use the Translate extension I think it's better to invest on the later (notably for supporting fallback languages in TNT and TNTN)
But still TNT and TNTN do dot work with legacy pages using non standard codes (which are not supported in the Translate extension; TNT and TNTN uses a workaround alloowing some coexistence).
Other issues to solve : some language codes are deprecated (notably zh-hans and zh-hant) but there are useful content to preserve there, and their content is not always translated to English, and it's still impossible to use another source language than English for translations meant for local projects not using English at all (e.g. pages from local chapters have their source in their own working language). So LangSwithc may be used instead.
Note that LangSwitch supports a list of language fallbacks. not found on any other wiki. I have maintained a small list of them, but if we want to eep LangSwitch, may be it could require a simpler Lua module to implement it).
But LangSwitch works as is and it is not complicate to use (notably for translating notice templates found at top of pages and expected to be displayed in the user language and not the content language.
TNT and TNTN now also support a selection of the language (by default it uses the content language, but it can also be called to use the UI language).
I have made these changes to avoi breaking the existant as much as possible, but migration to a newer system will require time.
LangSelect on the opposite should be deprecated completely here (it is really ugly, but it comes from Commns where it is still used a lot in file description pages). You should not find it anywhere now in new pages. verdy_p (talk) 00:29, 5 May 2014 (UTC)Reply
With that in mind, what wording can we use to discourage people from using it? I placed {{Historical}} to do that - but concede that it implies the content itself is outdated, which it technically is not. A note at the top encouraging people to use Translate instead? Should it mention LangSwitch? --Varnent (talk)(COI)02:02, 5 May 2014 (UTC)Reply
