Template talk:Multi-lang

Subpages

I just noticed that this template doesn't work well on non base pages. It can't find translation pages if used on the English version of a subpage. MediaWiki Help pages, from where I took this template, restricts the the use of subpages, so it's OK for them. However, SL wiki is full of subpages, and this is a problem...

-- Alissa Sabre 19:03, 10 September 2007 (PDT)

I'll put fixing this on my todo list. -- Strife Onizuka 21:51, 10 September 2007 (PDT)

Fixed, it's not perfect but it should work. -- Strife Onizuka 18:12, 20 September 2007 (PDT)

Wow! It's working as intended now. Thank you for the fix. -- Alissa Sabre 04:07, 23 September 2007 (PDT)

Chinese

Note to all editing template: Chinese has two different scripts which are NOT mutually understandable. The terms traditional and simplified apply to the different scripts, and NOT the grammar. For more information, please see the Wikipedia article about Chinese characters

Possible need to support ISO 639-3

The two codes currently used for Chinese text aren't supported by the template code.

So you've got 4 choices:

1. Pick one variant of Chinese and stick with it, using that variant with zh
2. Bork the template to support zh-Hans & zh-Hant, and bork all future needs to use unsupported codes
3. Make the template support ISO 639-3 as well
4. Migrate everything over to ISO 639-3

--SignpostMarv Martin 08:59, 17 December 2007 (PST)

I'm in favor of the last because it solves the immediate problem with only a little code change. Extra footwork but it such is life, it's better for the server then #2 or #3. One thing I do want to do is change it so the user can specify the language of the base article and not have the template automatically assume it is English. I do not want to see a hack put in place in the template, it makes maintenance down the road more complicated. Picking a single variant of Chinese does make some sense; the fewer languages we have people authoring content in the more unique content we will have (the more languages the longer it will take to translate that content into other languages; translation time is time that could have been spent authoring original content; the down side being you may not entice some users to contribute because their language isn't served that otherwise would be).

-- Strife Onizuka 21:12, 17 December 2007 (PST)

• Multi-lingual base articles would be good for portals and User-space articles.
• Option 4 would require all current translated articles be moved to their ISO 639-3 equivalents, so its not just a simple minor code change.
  • On the other hand, ISO 639-3 supports Klingon :-p

--SignpostMarv Martin 00:12, 18 December 2007 (PST)

I meant by simple code change, that the work required on the templates would be simple, the articles are another matter. Moving all the pages would be tedious if done by hand, I would write a GM script to automate the task. Lets schedule the implementation of #4 for next week? -- Strife Onizuka 02:08, 30 December 2007 (PST)

As was pointed out to me with my recent batch edits, I hope you configure the (presumably GreaseMonkey ?) script to mark the edits as bot edits.

The other thing to take care of would be to inform all the Residents & Volunteers via the relevant translation project pages that the multi-lang template will be switching to a different system.

SignpostMarv Martin 04:32, 30 December 2007 (PST)

Will do both. I'd like to see an Egyptian (Ancient) translation, or maybe Blissymbolics. -- Strife Onizuka 11:21, 30 December 2007 (PST)

As the manual for the code generator indicates, Klingon is also supported by ISO 639-3, although it does unfortunately appear to be using Western characters :-P

SignpostMarv Martin 01:22, 31 December 2007 (PST)

I'm moving the articles first then going to push the new templates. -- Strife Onizuka

You know what? I'm not sure if LL is aware of this plan. Will need to chat with them about this. -- Strife Onizuka 06:20, 8 January 2008 (PST)

lang, xml:lang and dir attributes

Should the template make some effort to support the (X)HTML attributes that aid in the rendering of multi-lingual, bi-directional text ?

--SignpostMarv Martin 00:12, 18 December 2007 (PST)

Uhhhh... Yes? Tell me more. -- Strife Onizuka 02:01, 30 December 2007 (PST)

See the W3C spec on the subject.

SignpostMarv Martin 03:50, 31 December 2007 (PST)

I *hate* reading W3C specs. Shouldn't be too hard to implement. I'll do some experiments. -- Strife Onizuka 15:55, 1 January 2008 (PST)

Articles in need for translation

Is it possible, that the template checks if an Italien/German/French(...) subpages exists in case it's added to the English parent (i know it already does) and in case such a page is not in existance, that it automatically adds the English (and only the English) page to a category named Articles missing xxx translation with xxx beeing the language which is missing? I know the answer is yes but I'm not able to implement it so could you, dear reader, do so? ^^
I guess it would be really helpful for us linguists and be more dynamic then Mentor Linguist Scribe Translation Project#Suggested Pages to Translate.
Greetz, Lynch ^{(talk|contribs)} 21:17, 2 June 2008 (PDT)

My only concern with doing so is that it will pollute the category sections of a huge number of articles. I really don't want to see this done until we upgrade to MediaWiki 1.13, which adds support for the __HIDDENCAT__ magic word. What I will do in the mean time is insert a hidden link to a language specific article (that won't exist), then you can use the Special:Whatlinkshere interface instead. -- Strife Onizuka 21:38, 2 June 2008 (PDT)

TYVM =) Was such an update ever mentioned anywhere? If not, can you open a JIRA for it and/or maybe add it to the Wiki Meeting Agenda (not that it would ever happen to take place but anyway ^^). -- Lynch ^{(talk|contribs)} 22:08, 2 June 2008 (PDT)

Hmm... I just realized that 1.12 is the latest regular release and that 1.13 is still in alpha. I'll write a jira as soon as it's officially released...

-- Lynch ^{(talk|contribs)} 22:09, 3 June 2008 (PDT)

It just came to my mind that, (in case the category adding or page linking version becomes deployed), the template should destinguish namespaces in the way that userpages are excluded from either cagegorizing or linking since they would clutter the category / what links here page.

-- Lynch ^{(talk|contribs)} 05:46, 6 June 2008 (PDT)

I was going to do this now but somebody used cascading permissions that is locking the templates. -- Strife ^{(talk|contribs)} 10:46, 18 August 2008 (PDT)

It's actually quite funny that exactly this "protection" had the sideeffect that Rob just unprotected it to fix your Jira (WEB-781), while it was a disputed "protection" in first place anyway. That said, I think that the issue written beneath is currently the more important one, since it blocks usability of upcoming translated versions of the Help Portal. If users don't understand the topics of the articles they are finding in help categories, it's unlikely they will start to have a look at them (or find the right one). TYVM, for your continuously efforts to tweak stuff as long until I stop complaining (^_^)

*hugz* Lynch ^{(talk|contribs)} 11:21, 18 August 2008 (PDT)

*reanimating this discussion* (^_^)

Since we got the now, should the template be changed? And can you look into the seperation of LSL articles from other articles? *bug*

Greetz, Lynch ^{(talk|contribs)} 18:01, 23 October 2008 (UTC)

I wish I saw this an hour ago, then I would have done it when I was working on LSL template changes. I'll put it on the top of the list. I have a few changes I want to make to the templates regardless (bug categories, 1.12 work around, etc). It should be noted though that there are still category issues. -- Strife ^{(talk|contribs)} 06:01, 24 October 2008 (UTC)

Kewl, thx :-) What kind of issues? Lynch ^{(talk|contribs)} 06:51, 24 October 2008 (UTC)

Articles in the wrong category & in the wrong order. I'm convinced it's due to the load sharing (two servers share the wiki, I believe they do not properly propagating the changes to their copies of the DB). -- Strife ^{(talk|contribs)} 14:24, 24 October 2008 (UTC)

I noticed that already bevore the update, translated LSL articles often were in the wrong (english) category until you browsed there and poked them (Edit -> Save, without changing content. Doesn't appear in history). This was not the normal cache problem that solved itself after some time. It was present for long when you didn't poke the articles.

I just noticed that the articles using Template:Help aren't including multi-lang anymore (o.O). Example: Linden Village. Ah... but I think I know why. I gotta investigate...

Lynch ^{(talk|contribs)} 14:29, 24 October 2008 (UTC)

Bug occurs in all included Template:Help localizations too when you force them to reload/poke them. This wasn't happening yesterday when I localized Template:Help/ja and Template:Help/ru so it's not directly connected to the update but to something else. *clueless*

Lynch ^{(talk|contribs)} 14:46, 24 October 2008 (UTC)

I'm having trouble getting the category stuff working, got to figure out how to get the 1.12+ parser to do what I want (which it isn't doing ~_~ and it's not entirely logical why it isn't doing it). -- Strife ^{(talk|contribs)} 15:08, 24 October 2008 (UTC)

Well, I made the change to Linden Village before you started to edit the multi-lang template. And it worked yesterday. So something happened meanwhile. Maybe the parser functions extension beeing upgraded which wasn't done during the update? What version was it before? Lynch ^{(talk|contribs)} 15:20, 24 October 2008 (UTC)

Well all LSL functions, events and constants are now out of the main NT space and into the subspace NT/LSL; still need to move categories, rouge articles. I'm thinking about changing the Template:LSL Header to include multi-lang (and set the category then). It would simplify things greatly and only require stripping the explicit declaration of multi-lang on articles... assuming the reoccurance code is working properly. I'll give some thought to it before I proceed with that. The alternative is to make a new header template that wraps both multi-lang and the lsl header templates. Anyway we cut it, it will require editing 100+ categories and unknown number of articles. P.S. still need to do LSL keywords. -- Strife ^{(talk|contribs)} 17:17, 24 October 2008 (UTC)

That looks really good so far! You know I'm an edit count whore (soooo close to get ahead of Torley now ^^) so in case I can help out with updating once the change is done: just gimme a shout. Btw: Template:Help and it's children are fixed again. Greetz Lynch ^{(talk|contribs)} 18:39, 24 October 2008 (UTC)

Oh no, I've slipped below 15% must do more work. -- Strife ^{(talk|contribs)} 19:09, 24 October 2008 (UTC)

I may have fixed Template:Help's multi-lang problem, that is a really weird bug, something in the wiki parser is fragile and that template breaks it somewhat (I ended up double testing to isolate multi-lang, multi-lang must be properly isolated or bad stuff can happen; but it shouldn't have caused what you were seeing). I decided to go with a hybrid solution, an optional multi-lang inclusion in the lsl header, which simplified the category injection problem... but required me to do something like 450 edits =^_^= -- Strife ^{(talk|contribs)} 02:08, 25 October 2008 (UTC)

P.S. I also managed to saturate the wiki's DB server connection to the point where it displayed errors.

hm... almost thought the link to the recent changes was broken and linking to Special:Contributions/Strife_Onizuka instead ^_^ You're simply nuts. Luv that though ^^

So I thought I had fixed the bug already in the help template.. hrm... o.O

And yeah noticed the DB error(s) o.O

Thanks for the changes! It benefits linguists a lot!! =)

Lynch ^{(talk|contribs)} 05:48, 25 October 2008 (UTC)

Feature request regarding upcoming changes in Project:Languages

In order to provide a better support for non-english speakers, articles should be allowed to be named in other languages too, to increase searchability. An In-World meeting about that came up with these ideas. Since WEB-457 isn't available (yet?) I'd like to request a slight change in the way this template here is working. Please see Project talk:I18n/native feature migration#Bridging the gap until implementation. Would that be possible? It shouldn't break anything...
Greetz, Lynch ^{(talk|contribs)} 06:28, 18 August 2008 (PDT)

Sorry... the feature is already implemented, as far as I can see *blind*

-- Lynch ^{(talk|contribs)} 20:52, 18 August 2008 (PDT)

Articles in need of updating

Heyas! =)
Can we change the Article in need of updating/ISO-Code style to a localized version? I put together a table of the categories currently in use by Template:Help:

Code	Cat
en	Category:Articles in need of updating
de	Category:Artikel die aktualisiert werden müssen
es	Category:Articles in need of updating/es
fr	Category:Articles à mettre à jour
it	Category:Articoli in attesa di rinnovo (update)
ja	Category:更新が必要なページ
nl	Category:Artikelen die bijgewerkt moeten worden
no	Category:Arikkler som trenger oppdatering
pt	Category:Artigos que precisam de atualização
ru	Category:Статья нуждается в обновлении

Greetz, Lynch ^{(talk|contribs)} 20:42, 13 November 2008 (UTC)

Hum... maybe it's not such a bright idea... These might be two different kinds of categories... "Translations in need of updating" and "Articles in need of updating". One would be the article itself (even the English base article) beeing out of date and the other would be that the english base got an up to date version but the translation is outdated... I think a change of the category to "Translations in need of updating" would do...(?)

These can then also have the language code since the ones editing it are supposed to be linguists anyway. I think...

Lynch ^{(talk|contribs)} 20:52, 13 November 2008 (UTC)

I'll get on it when I've got some time (right now is so bad you wouldn't believe). -- Strife ^{(talk|contribs)} 08:29, 14 November 2008 (UTC)

I'm currently not sure in which way the change would be best - that's why I made the two comments so shortly after another. I tend to the later at the moment. And then maybe categorize the "Translations in need of updating" as subcategory of "Articles in need of updating". While it's not a real subset... hrm...

And no need to hurry. I currently can't see a flood of linguists conquering the Wiki who might be looking for these cats.

Hope you're doing better soon :-S

Greetz & hugz, Lynch ^{(talk|contribs)} 09:22, 14 November 2008 (UTC)

Brainstorming:

• Category:Articles in need of updating | Handled by Template:Multi-lang and Template:Help
  • Subcategory 1:Translations in need of updating | Handled by Template:Multi-lang
  • Subcategory 2:Content in need of updating | Handled by Template:Help with OldInfo=*

and all of it localized... (^_^) *tongue click*^[1]

Maybe both Template:Multi-lang and Template:Help forward the request for Category:Articles in need of updating to a third template, so there is no need to update two translation lists.

Lynch ^{(talk|contribs)} 13:33, 14 November 2008 (UTC)

Now I'm confused x_x; I'm sure it will make more sense later (my brain is elsewhere). -- Strife ^{(talk|contribs)} 15:11, 14 November 2008 (UTC)

I'm sure it was the tongue clicking ^^ Hope you find it again :-) Lynch ^{(talk|contribs)} 16:21, 15 November 2008 (UTC)

1. ^ *tongue click* is the sound that occurs when you click your tongue. Like the donkey does during the journey to "Far Far Away" in the movie Shrek 2. A manual

Google translation links

Hey there!
I added a new feature to this template, which shows Google translation links for those pages only where no volunteer translation is available. I received both, very positive and negative feedback to this change, so I thought it might be good to ask for a community (or Linden) decision on this topic.

• Contra:
  • Machine translations can (and often: do) deliver a poor translation of an article.
  • Poor translations of LSL articles might lead to not working scripts.
• Pro:
  • A poor translation might be better than no translation at all, for someone seeking for help. They see that it is a machine translation (with poor grammar) and therefor might know that they need to be careful with the presented information.
  • A poor translation might encourage people to provide a better translation. The template change involves a new info bar beneath the language bar, which points out how to provide (better) volunteer translations.
    • This information bar can be localized into different languages. The right localized version becomes included in the volunteer localized pages, with a default fallback to the English info bar, in case no localized info bar is available.

On the template itself: It only provides the Google links in case there is no other translation. Otherwise the Google link is replaced with the link to the volunteer translation. The template highlights Google and volunteer translations in different colors, to make them easily distinguishable. See Help Portal for an example on how this looks like.
Question 1: Keep or discard this change?
If the answer is keep → It should be possible to exclude this features from all LSL Portal related pages.
Question 2: Exclude from LSL pages or keep it for all pages?
Greetz, Lynch ^{(talk|contribs)} 22:54, 11 March 2009 (UTC)

I'm strongly in favor. True, it will lead to bad translations. But a bad translation can be refined to be a better one by many people who would never take on the task of translating the whole entry.--Omei Turnbull 19:28, 12 March 2009 (UTC)

Two Thumbs Up for #1 Keep and #2 Keep. I wish it could be on User pages, too. I like to send links to Lum Pfohls help pages in-world, and half the world can't understand them. --Ferd Frederix 21:27, 12 March 2009 (UDT)

Thx :-) Re:Usage at Lum's pages: The template is not namespace dependant. Or in other words: You can just ask Lum to add {{multi-lang}} to her page and it will display the language bar.

Greetz, Lynch ^{(talk|contribs)} 04:06, 13 March 2009 (UTC)

Snazzy. I see no reason not to use it on LSL pages. It should however be worked into the multi-lang table so that the styling is consistent (a bit of a pain to do since the boarders, background and cellspan need to be manipulated). I'll get on it. -- Strife ^{(talk|contribs)} 02:02, 16 March 2009 (UTC)

Looks neat, THX! :-) Lynch ^{(talk|contribs)} 08:22, 16 March 2009 (UTC)

I personally don't like the current format, because of the following concerns:

• The Multi-Lang block looks too heavy for me in the current format. I don't know under what criteria you chose the current set of X languages, but the list doesn't fit in a line when shown on my screen. I will never object to have a lot of translations that can't fit in a line as long as they are high quality translation, but just list bunch of links to google translation pages using multiple line seems unworthy to do. Moreover, we currently have "Volunteer translated pages are linked in blue..." message that also doesn't fit in a line.
• I'm not sure how much benefits the machine translation links gives to users. I agree machine translated page can be better than not translation at all, but I believe it's easy to manually invoke google translation.
• I don't agree with Zai's opinion regarding "showing poor translation encourages people to provide a better translation." At least in my case, if I see a manually translated bad Japanese, I would happily correct the text. However, when I see machine translated Japanese text, I simply ignore it. (Of course, I may be the only one who behaves so... I have no statistics handy. :-)

SO, I suggest just adding one link to google translation page at the end of the list of languages. I believe such link provides almost all benefits from the current scheme, maintaining simple Multi-lang block. --Alissa Sabre 09:16, 20 March 2009 (UTC)

You make good points. It is heavy and more so when used from the built in web browser. Maybe we could have 3rd party page (3d party like the JIRA mirror) that lets you select the target language and stores it in a cookie; with the cookie it would auto translate into that target language? Kinda solves several problems. I know what the criteria was, it was the ones people tried to translate things into (which got hardcoded into Multi-lang), which isn't the greatest criteria, it doesn't scale. -- Strife ^{(talk|contribs)} 17:51, 21 March 2009 (UTC)

Yes, Strife is right about the (pseudo)criteria. It were the ones selected at the original template, plus those which were requested by voluntary translators over time (I think at least Swedish and Hebrew were added). I'd love to see something like WEB-235 beeing deployed to solve the cluttering. Looks fine on my screen but I can imagine that it is disturbing when broken into many lines. However, the "Volunteer links..." message shouldn't wrap with normal font size and a resolution of at least 800x600 (tested in FF 3.0.7 in Ubuntu 8.04), which might be standart for anyone who accesses Second Life.

I'm not sure if I understand the 3rd party page idea...(?)

Hmm... Guess the "just one link" approach would be an idea,,, *thinks*

Lynch ^{(talk|contribs)} 03:13, 22 March 2009 (UTC)

• It's been a while since this has last been discussed. I think this is not only unwieldy, it also makes it hard to differentiate between human translated articles and a link to machine translation (on an external site no less). Especially when it's stacked on top of another header like in the Help categories. And with languages right into the sidebar, I'm not even sure if this template is necessary. --Geneko Nemeth 03:59, 8 August 2009 (UTC)

I got to admit that I thought about this too... Not that it would be confusing (I think it works well - for me - with the different colors for the links) though contrary to my comment in the JIRA, I think that the navigation bar is going to clutter the Wiki pages to much. We're having up to three different headers on top of a single page (multi-lang, help header and lsl header) and it seems to become the same way with the imported KB articles (see Template:Seal)...

BUT I think that the language links in the sidebar are overlooked by most wiki users who aren't using the wiki on a regular basis. I see this often by friends who use the Wikipedia. They just seem to not notice these links.

Currently, my suggestion would be, to remove the the language table from this template here (the other functionality should stay and the template should continue to be included in articles, since it has numerous other benefits). Furthermore, something like

#p-lang .pBody{ 
    background-color:#FEFFCC;
}

should be added to MediaWiki:Monobook.css to highlight the language links. I would not want to loose the language table without such a highlighting enabled.

-- ^{(talk|contribs)} 04:22, 8 August 2009 (UTC)

My suggestion would be

<css>#p-lang {

 background-color: rgb(254,255,204);
 border: 1px solid #AAAAAA;
 margin-bottom: 10px;

}

1. p-lang .pBody, #p-lang h5{

 background-color: rgb(254,255,204);

}</css>

It would look like File:Sidebar multi-lang highlight.png. I would suggest that in the JIRA when there's no objection to get rid of the current multi-lang table.

-- ^{(talk|contribs)} 16:04, 10 August 2009 (UTC)

I don't mind getting rid of the header but I don't like the idea of highlighting the lang block on the left. However I do recognize that without it being highlighted people won't notice it. -- Strife ^{(talk|contribs)} 02:31, 11 August 2009 (UTC)

Hm... So you're saying "I recognize it's useful but it draws to much attention there/looks ugly so I don't want to have it" or "I think it's ugly/draws to much attention but looks like the lesser of two evils"?

In case WEB-1187 would be fixed, users could switch it off again (though I realize that practically no one would notice that they had this ability).

-- ^{(talk|contribs)} 10:48, 11 August 2009 (UTC)