[Unicode]   Common Locale Data Repository : Bug Tracking Home | Site Map | Search
 
Modify

CLDR Ticket #10038(closed data: wontfix)

Opened 4 months ago

Last modified 7 weeks ago

Wrong name for Indonesian in Indonesian?

Reported by: roubert Owned by: kristi
Component: main Data Locale:
Phase: dsub Review:
Weeks: Data Xpath:
Xref:

Description

Changeset r11798 pulled data from the Survey Tool changing the name of Indonesian in Indonesian from "Bahasa Indonesia" to just "Indonesia" and this was released with CLDR 28:

http://unicode.org/cldr/trac/changeset/11798/trunk/common/main/id.xml

Now we (Android) have received a bug report claiming that this was a mistake and that the name should never have been changed.

Attachments

Language_comparison.png (85.1 KB) - added by roubert 4 months ago.

Change History

comment:1 Changed 4 months ago by kristi

  • Cc kristi added

comment:2 Changed 4 months ago by emmons

  • Owner changed from anybody to kristi
  • Priority changed from assess to medium
  • Status changed from new to accepted
  • Component changed from unknown to main
  • Milestone changed from UNSCH to 32

comment:3 Changed 4 months ago by pedberg

Currently the language names are intended to be used in a context where it is evident they are language names. CLDR has a pattern that can be used to provide this context if desired, e.g. in Indonesian:

<localeDisplayNames>
    ...
	<codePatterns>
		<codePattern type="language">Bahasa: {0}</codePattern>

Perhaps we should use that pattern to display language names in the Survey Tool?

Because that context is assumed, we generally do not use "Bahasa" (i.e. "language") in language names in Indonesian or Malay.

Last edited 4 months ago by pedberg (previous) (diff)

comment:4 Changed 4 months ago by pedberg

  • Cc pedberg added

comment:5 Changed 4 months ago by kristi

In addition to looking at this for Indonesian data, a possible solution discussed is a change in the Survey tool to append "Language:" for a clearer context.

comment:6 follow-up: ↓ 7 Changed 4 months ago by roubert

If codePattern type="language" really is supposed to always be used with these strings, then there would be another problem with this data, several of the strings do currently already contain the word Bahasa:

<language type="ase">Bahasa Isyarat Amerika</language>
<language type="cu">Bahasa Gereja Slavonia</language>
<language type="mul">Beberapa Bahasa</language>
<language type="mus">Bahasa Muskogee</language>
<language type="und">Bahasa Tidak Dikenal</language>

But I don't think that's the case, most code I've ever seen just takes these strings and use them stand-alone directly. When was the last time you saw code using CLDR data formatting "Language: English" in its user interface, instead of just "English"?

comment:7 in reply to: ↑ 6 Changed 4 months ago by pedberg

Replying to roubert:

If codePattern type="language" really is supposed to always be used with these strings, then there would be another problem with this data, several of the strings do currently already contain the word Bahasa:...
But I don't think that's the case, most code I've ever seen just takes these strings and use them stand-alone directly. When was the last time you saw code using CLDR data formatting "Language: English" in its user interface, instead of just "English"?

I was not suggesting that the codePattern was always used or needed, just that there is usually some context that makes it evident that these are language names. For example, some user interface might say "Choose a language:" followed by a popup menu with these language names.

And as far as the use of "Bahasa" in the names for "mul" and "und" I think that is OK, these names mean something like "Multiple Languages" and "Undetermined Language" so the word for Language is probably necessary in the name. For the other three it is probably an error.

Last edited 4 months ago by pedberg (previous) (diff)

Changed 4 months ago by roubert

comment:8 Changed 4 months ago by roubert

I've now attached a screenshot from the people who reported this bug to us, illustrating why they think that changing the string from "Bahasa Indonesia" to just "Indonesia" was wrong.

comment:9 Changed 3 months ago by kristi

Whether to include "language" in the language name in the context of a language name list has been one of the broader issues that we've seen across all languages. We continue to monitor/work on this per language with the goal being CLDR data quality.

In case of "Bahasa Indonesia", we don't recommend switching back to "Bahasa Indonesia" this was one we have reviewed with our vetter initially:
"For the language pattern, since they're under Language category, it is preferred to remove the word "Bahasa", so the name won't be too long. The word ‘Bahasa’ is normally used together in a sentence”.

As for the suggestion to add the code pattern in the Survey Tool, the last example in the example pane (right pane) already show the codepatter for "Language:".

A few general comments:

  1. Appending “language” in the language name is a broader questions.
  2. In generally, in the future, I'd like to recommend that we validate such changes with vetters before the changes are made by TCs.
  3. We’ve noticed the preference by vetter to lean toward appending “language” when it’s the native name. The scenario may be more real for them since they'll encounter the native names more often than other translation and they may have a stronger feeling toward the native name.
  4. We also explored whether the native language names should be treated as an exception in terms of consistency with other language names, but it depends on the language. Although, generally consistency would be preferred than having exceptions for the native name.

If those on Cc are okay with this feedback, I can close this ticket as by design or suggest to bring this up in the forum during v32.

comment:10 Changed 7 weeks ago by kristi

  • Status changed from accepted to closed
  • Resolution set to wontfix

Closing since no additional comments have provided from those on Cc.

View

Add a comment

Modify Ticket

Action
as closed
Next status will be 'new'
Next status will be 'closed'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.