Difference between revisions of "Project talk:Languages"

Revision as of 06:40, 20 April 2009

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)

@@ Line 56: / Line 56: @@
 :Yes, a local page <u>'''and'''</u> 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, [[Image:Zai_signature.png|45px]] '''[[User:Zai Lynch|Lynch]]''' <sup><small>([[User talk:Zai Lynch|talk]]|[[Special:Contributions/Zai Lynch|contribs]])</small></sup> 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 {{HoverText|barbarian|Historic Derivation: The word is onomatopoeic, the bar-bar representing the impression of random hubbub produced by hearing a spoken language that one cannot understand}} 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 <code><nowiki>{{Foreign|sabotage|word|French|Destroy property or hinder normal operations.}}</nowiki></code> and it would render something like {{HoverText|sabotage|French word which in this context means: Destroy property or hinder normal operations.}}. 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.
+-- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 14:40, 20 April 2009 (UTC)