Project talk:Languages

Some notes

I prefer use of ISO 639-1 alpha-2 codes for language identification, because it covers most of the major languages and it is the common practice of IT industry today. I believe 639-2 alpha-3 is overkilling for the projects like SL wiki, but it can co-exist with alpha-2 codes, and I added some wording on the possibility of their uses in a future. Use of ISO 639-3 doesn't make sense. (Who wants to have pages in such rare languages?)

I just taken the page title convention from MediaWiki web site. It is primarily consistent with the existing practice on this SL wiki.

I know that Project talk:I18n#Translated versions of an existing article says some different convention on the page translation, but I ignored it, primarily because I don't think ISO 639-3 is a good choice (see above for this point), and entire page and its associated project page doesn't look like a page to cover I18N (internationalziation) issues on SL wiki project. The page is for a group activity called "I18N project". (I believe the author of the page didn't know the purpose of MediaWiki's project name space...)

I know that a set of pages Voice Mentors: Getting Started with Voice and its (incomplete) translations uses similar but different convention. I believe the differences are small, and we can migrate in a future.

-- Alissa Sabre 23:58, 7 September 2007 (PDT)

Supported Languages

I noticed that the list of supported languages shown here and that for viewer UI (shown on How to Localize Your World).

Languages only supported as a wiki page:

• Ilalian
• Dutch

Languages only supported as a viewer UI:

I also noticed that the list of supported languages in Template:Languages-spoken is very huge; it looks like covering all ISO 639-1 languages. (Although I've not verified...)

I personally don't care the disagreement in this case. Opinions?

-- Alissa Sabre 18:57, 10 September 2007 (PDT)

Template:ISO_639-3/cat-speaking contains all ISO 639-3 languages in their english spelling.

-- SignpostMarv Martin 18:02, 12 October 2007 (PDT)

I agree having more wiki languages than viewer languages can make sense. I think we say "Ilalian" here to mean "Italian". I, for one, have used the English viewer to chat in Italian.

-- Ppaatt Lynagh 08:08, 4 November 2007 (PST)

Korean is supported both as a UI(SL Client) and as a wiki.
-- Nanjido Oh 17:47, 11 March 2009 (UTC)

Each lang code categorys

In LSL Portal, each languages have categorys. Example,Category:LSL is Category:LSL/fr and Category:LSL/ja, with lang codes. But this is LSL Portal only now. I also want to organize each langs pages with each langs category in other portals. Asuka Neely 04:24, 25 February 2008 (PST)

Originally we weren't going to have the translated articles in categories but I realized that it would aid usability if we did. Having all of them go into a single set of category pages resulted in them getting too busy so we split them. There is no reason I see not to carry the practice across the entire wiki. Strife Onizuka 06:28, 25 February 2008 (PST)

Got no idea why it took me so long to notice this discussion... so let's bring it back to life. I'm going to announce a meeting which should take place within the next two weeks and which should/might have a "final decision" on that topic (at least until someone yells at us ^^)

So the solution I'd like to see is: Leave the LSL Portal as is but provide this for non-lsl articles:

• Create a translation of the category (like Category:Tutorien <- this would be German for "Category:Tutorials"), create a categorized page with the translated articlename that redirects to ARTICLENAME/languagecode. In this example the page would be named Video Tutorien and it would redirect to Video Tutorials/de.

Will keep you posted. Cheers, Zai Lynch^{(talk|contribs)} 21:58, 26 June 2008 (PDT)

Merge or Distinguish

Since both projects are Resident obtained, I can't see the reason of a Project:Languages and a Project:I18n. I think they are kinda the same and just confuse potential contributors. So I'd like to either see them merged into one project or distinguished in a way, that it's easily spottable where the differences are. E.g. goals presented via keywords. My vote is for the merge version atm btw. Greetz, Zai Lynch^{(talk|contribs)} 21:58, 26 June 2008 (PDT)

Guideline for creating "local language page titled" page

So current updates suggest that "should be in the same language as the article itself", Is that means when we making NEW page, we don't have to make such as "help/ja" page anymore? Or should I better making local title page AND "help/ja" then tied them with redirection? -- Nock Forager 02:30, 26 September 2008 (PDT)

Yes, a local page and a page in the Name/LanguageCode style (like help/ja). The help/ja would redirect to the translated page (not the other way around, so articlenames in categories are displayed correctly). The reason why this is needed is, that Template:Multi-lang wouldn't be able to find the translated page otherwise. It just tests for Name/LanguageCode. Note that Template:Multi-lang needs a small modification on the translated page (parameter 1 and 2). I also tried to make a video tutorial for this and linked it to the Mentor Linguist Scribe Translation Project.

Greetz, Lynch ^{(talk|contribs)} 05:25, 26 September 2008 (PDT)

Foreign phrases

I was looking at プリム (out of curiosity, I can't read Japanese and I only know how to say about a dozen words) and I noticed how parts of it were left in English, not because they couldn't be translated but because portions of the SL interface haven't been translated or it doesn't make sense to translate them. It made me stop and think about the user experience:

The user is reading the article when they come across this barbarian phrase that they have no handle on, they may not even understand how the alphabet that it is written in works. They can't read it, they can't say it, it is an enigma for which they lack a key to unlock it.

There is no getting around it, this is a bad user experience, for this reason, I propose the use of ToolTips to help add meaning to these phrase. The user can then hover their cursor over the link and read the derivation of the phrase. This could be streamlined in a new template so you could have something like {{Foreign|sabotage|word|French|Destroy property or hinder normal operations.}} and it would render something like sabotage. Employing this would expand the understanding of our readers and introduce them to other languages; and no more inferring the meaning from context. With languages with non Latin based alphabets this problem is quite glaring.

As for the LSL article implications, I'm thinking about adding a DeepNotes subsection that explains how the function was named; which when the article is translated could be ballooned out into something that teaches a tiny bit of English. -- Strife ^{(talk|contribs)} 14:40, 20 April 2009 (UTC)

Hm... So when it is aimed to words which would be translateable but just aren't translated so far since the localization of the UI lacks behind, I'd think that an attempt like at プリム is clearer. People know what "wood" is (for example), when they can read it in their language, so it doesn't need futher description, but definatly needs a translation connected on first sight (rather than hovertext where it takes more time to discover it).

I used the hovertext attempt at some of my LSL related translations, where a term is translated in the UI but where I considered it beeing a non-intuitive translation for someone who uses the English client (like most Germans who I know do) but reads the German documentation.

Besides the terms which aren't translated yet, I'd think of at least two more cases where English terms could appear in localized texts:

1. names
2. anglicisms / loanwords

I think it should be obvious in the text when a name appears and in case the name needs further explanation, it would/should have internal or external links to descriptions. Tho maybe this attempt can be used for the loanwords, to give an explanation / describe them. I think that is what you did with "sabotage" and am thinking that it would be a good idea.

Lynch ^{(talk|contribs)} 22:18, 20 April 2009 (UTC)

Hmmm I see that I'm late to the party, thought and action have already taken place with this. Shouldn't have been so naive to think this problem hadn't already been spotted; curse of the monolingual. -- Strife ^{(talk|contribs)} 12:08, 21 April 2009 (UTC)

Though you're the first one who made it public. All others who spotted it (including myself) tried to tinker an own private work-around. The hovertext wasn't my first attempt btw. The first one was a template linking to LSL Glossary/de, in order to link all terms in need of explanation over there (easier to keep up-to-date). Though I never really finished it... I should get back to translating LSL articles anyway, when I find the time and patience again. *hrm...*

Lynch ^{(talk|contribs)} 18:09, 22 April 2009 (UTC)

This is a good point and touches on a big problem: transparency... I know I'm terrible at it (I don't even bother to fill in the Edit Summary field) but then there isn't much incentive to being transparent, only a half dozen people will read it and won't comment (comments are rare on the LSL (Function) Template todo list... though it is mostly technical). We individually spot problems and we try and solve them as best we can on our own without much in the way of consult. It is my worry that I am out of touch with what the community wants or needs. -- Strife ^{(talk|contribs)} 14:11, 23 April 2009 (UTC)

Hm.. when you're worrying about that, there might be a way how to find out what the users are missing. We could make a survey monkey to gather feedback on what people like about the LSL Portal (for example), what they don't like, what their suggestions were on how to make it better, etc. We could make the Template:LSL Header include a Template:Hint (or something less disturbing) with the link to the survey for, say, two weeks or so. Everyone who frequently reads LSL articles would stumble upon it and hopefully some would take the survey and provide feedback. Benefit from it over a forum posting or discussion page entry would be, that it would reach exactly the target audience: the ones who read articles in the portal.

Lynch ^{(talk|contribs)} 23:42, 23 April 2009 (UTC)

*laughs* a prime example of us making up our minds without asking others, I already made a forum thread asking for input: http://forums.secondlife.com/showthread.php?t=317701

I like the survey idea, and it will give us some actual statistics but I suspect we would max out survey monkey plans very quickly. We should ask LL if they have a subscription with a survey service. I'll post a JIRA about getting an LSL survey? -- Strife ^{(talk|contribs)} 05:37, 24 April 2009 (UTC)

^^ Oh yes, can :-) JIRA or SLDEV mail. Though I'm pretty sure that they got no subscription with another service, since VTeam used survey-monkey excessivly to gather data from volunteers and the CT Projects are still using it for the registration. So I think if they had payed for another service, they'd tell their employees to use that one instead. Though you never know ^^ *reads the thread* -- Lynch ^{(talk|contribs)} 10:01, 24 April 2009 (UTC)

Updated pages

What's the recommendation for translated pages when the page is substantially updated and changed? There's no recommendation for that. GW ^(T|C) -- 22:35, 25 May 2009 (UTC)

Hmm... we have an undocumented feature in Template:Multi-lang which allows us to set a version number for a page and to adjust that version number on any translated page. If the version number of the translated page is lower than the version number of the parent page, it can display a warning box. I think I should put the documentation of that feature on my to-do list... Lynch ^{(talk|contribs)} 22:49, 25 May 2009 (UTC)

Or on my todo list... we really should move the documentation for it into a subtemplate to be transcluded (so we can modify it without it forcing an update to all the articles; see Template:PBR for an example of what I mean.). -- Strife ^{(talk|contribs)} 23:41, 25 May 2009 (UTC)

Why do I suddenly get the feeling that you two hold secret meetings to conspire against the rest of us and are plotting to take over first the wiki then the world. In all seriousness version numbers seem like a good way to do this although unless it's easy to use we'll be stuck with people not using them which will lead to even more confusion. GW ^(T|C) -- 06:24, 26 May 2009 (UTC)

Oh come on, secret meetings? That is so unwiki, we would never do that, we just spread them out over many talk pages. Joking aside, we could do it by peaking at revisions dates but we aren't running MediaWiki 1.15 (and it probably wouldn't work to well either). The versioning as it is currently written works but isn't very friendly, a better solution would be an extension that didn't require a subpage. I'm thinking we could have some global key-value-pair dictionary that backs up on a database (otherwise it will be sitting in memory!). The tricky part will be stopping memory leaks, that is making sure entries for deleted pages get purged. I'd also use the db to house tooltips (they are such a pain). Would probably still use the subpage, to store the key (so we can keep them short; I don't think we need more than 16 chars in a key). -- Strife ^{(talk|contribs)} 12:33, 26 May 2009 (UTC)

Continued musings...

Or maybe the metainfo could be attached to the articles as a group, that is piggyback somehow on the interwiki linking that gives us "In other languages" the links in the left side. Essentially an implicit include? hmmmm. I need to build a table to plot out the possibilities,

• Versioning Extension with ability to grab the number from anywhere <= best solution
  • Issues:
    • Could have a nice interface.
• Render Groups <= needs a new extension or the inadvisable use of templates ^_^
  • Issues:
    • No nice interface but easy to use for other tasks.
    • Could be implemented with templates (hello VariableExtension)
  • Proposed syntax for custom extension:
    1. Tagging: <render class="a,b,c">I'm only rendered for groups a, b and c</render>
    2. Toggling: <render show="c,d,e">any code between, including that which comes from templates will only get called if it is in the groups c, d & e</render>
    • The two syntax's can be combined. I don't know why anyone would want to.
  • Template Implementation: https://bugzilla.wikimedia.org/show_bug.cgi?id=18939

--Strife ^{(talk|contribs)} 19:36, 26 May 2009 (UTC)

When I remember right, the version number idea bubbled up in connection to translations of the Volunteer Portal, which contained guidelines and sometimes dead-lines and that kind of stuff. There seemed to be a need for it, since an outdated translation might have had negative consequences for the volunteer reading it, considering that an outdated guideline would still be part of a translated page or the page wouldn't contain a new guideline, etc. etc.

I guess it can be a benefit, once the test pilot plan moves on and more critical content is added to the wiki (like stipends and such). It's nice to have a chance to mark these as out-of-date on translations. So I think once that happens, the documentation team will need to learn how the feature works.

For "normal" (low priority) wiki articles (like avatar or so), I don't think that the feature needs to be used. I'd even go so far and say that forked versions in different languages might be fine, since the number of translators in some languages is really low, while there might be some people who don't speak English but who'd be able to fill the gaps with valuable content. It's similar to what the Wikipedia does. The French, German, Russian, (...) version of articles are totally different and independant from the English versions. That seems to work better than just translating the English Wikipedia.

@Strife: Yeah, seperating the documentation from the template is a good idea. Not yet sure about the global database vs. the version subpages...

-- Lynch ^{(talk|contribs)} 18:31, 26 May 2009 (UTC)

Yeah, we never did force versioning down the users throats (and given the correct parameter) it can be disabled on the entire article group or just the specific article (set the version to -1). -- Strife ^{(talk|contribs)} 19:36, 26 May 2009 (UTC)