Mapping locale to language name via the YML file

[Henrik N]

This is fairly obvious, but I thought I'd share since I haven't seen
quite this solution mentioned elsewhere.

I wanted some way to map a locale (e.g. :en) to the language name
(e.g. "English") for a select box. Rather than stick the info in a
database, hash or some other separate record, I put it in the YML file
of the locale itself:

# config/locales/en.yml

en:
meta:
language_name: 'English'

Then made an I18n method to read it:

# config/initializers/i18n.rb

module I18n

def self.name_for_locale(locale)
begin
I18n.backend.translate(locale, "meta.language_name")
rescue I18n::MissingTranslationData
locale.to_s
end
end

end

Used like this:

I18n.name_for_locale(:en) # => "English"

As a gist here if you want to fork and improve: http://gist.github.com/276191

Can anyone see issues with this? I just started using Rails i18n the
other day, so I may well be missing something.

Perhaps it would be a good idea to add this info (but with a better
key… meta.name? language.name?) to all translations in the rails-i18n
repo?

[Sven Fuchs]

Hi Henrik,

On Jan 14, 2010, at 7:56 AM, Henrik N wrote:
> This is fairly obvious, but I thought I'd share since I haven't seen
> quite this solution mentioned elsewhere.
>
> I wanted some way to map a locale (e.g. :en) to the language name
> (e.g. "English") for a select box. Rather than stick the info in a
> database, hash or some other separate record, I put it in the YML file
> of the locale itself:

...

Thanks for the suggestion! I've added a link to http://rails-i18n.org/wiki (see "Code Snippets")

> Can anyone see issues with this? I just started using Rails i18n the
> other day, so I may well be missing something.
>
> Perhaps it would be a good idea to add this info (but with a better
> key… meta.name? language.name?) to all translations in the rails-i18n
> repo?

In the Pluralization module we've introduced the key :i18n as a meta namespace for locales because "i18n" might be a less often used key compared to "meta". Not sure this is a big one, but maybe we should agree on this convention.

So maybe I'd change the key to "meta.language.name".

I guess in the end we'd want complete translations of language names for all locales. I.e. we'd want to be able to translate English "English" to German "Englisch" as well as English "German" to German "Deutsch". That's a big number of translations but all that data is provided by CLDR (e.g. http://unicode.org/cldr/apps/survey?_=sv&x=languages) which is why I haven't tried adding it to the rails-i18n repository. The ruby-cldr gem should already be able to make language names available to I18n (or just Ruby respectively)

[Henrik Nyh]

On Sun, Jan 17, 2010 at 16:00, Sven Fuchs <sven...@artweb-design.de> wrote:
> On Jan 14, 2010, at 7:56 AM, Henrik N wrote:
>> This is fairly obvious, but I thought I'd share since I haven't seen
>> quite this solution mentioned elsewhere.
>>
>> I wanted some way to map a locale (e.g. :en) to the language name
>> (e.g. "English") for a select box. Rather than stick the info in a
>> database, hash or some other separate record, I put it in the YML file
>> of the locale itself:
> ...
>
> Thanks for the suggestion! I've added a link to http://rails-i18n.org/wiki (see "Code Snippets")

Good idea, thanks!

> In the Pluralization module we've introduced the key :i18n as a meta namespace for locales because "i18n" might be a less often used key compared to "meta". Not sure this is a big one, but maybe we should agree on this convention.
>
> So maybe I'd change the key to "meta.language.name".

I'm guessing you meant to say i18n.language.name. That makes sense.
Updated the gist accordingly.

> I guess in the end we'd want complete translations of language names for all locales. (...) That's a big number of translations but all that data is provided by CLDR (e.g. http://unicode.org/cldr/apps/survey?_=sv&x=languages) which is why I haven't tried adding it to the rails-i18n repository. The ruby-cldr gem should already be able to make language names available to I18n (or just Ruby respectively)

I agree including all that data in the regular yml files in the repo
would be too much.

One could argue that you only really need to list each language in its
native form, as someone who doesn't know what "Deutsch" is wouldn't
want to select that anyway. In that case, it's only one new key per
file, so it could make some sense to include it in the repo.

Then again, I'm sure there are valid and common use cases for
non-native language names, and including metadata may be a slippery
slope, so I won't push the idea further.

Thanks a lot for the feedback, Sven!

[Sven Fuchs]

>> So maybe I'd change the key to "meta.language.name".
> I'm guessing you meant to say i18n.language.name. That makes sense.

Argh. Obviously, yes :)

> Updated the gist accordingly.

Cool!

>> I guess in the end we'd want complete translations of language names for all locales. (...) That's a big number of translations but all that data is provided by CLDR (e.g. http://unicode.org/cldr/apps/survey?_=sv&x=languages) which is why I haven't tried adding it to the rails-i18n repository. The ruby-cldr gem should already be able to make language names available to I18n (or just Ruby respectively)
>
> I agree including all that data in the regular yml files in the repo
> would be too much.
>
> One could argue that you only really need to list each language in its
> native form, as someone who doesn't know what "Deutsch" is wouldn't
> want to select that anyway. In that case, it's only one new key per
> file, so it could make some sense to include it in the repo.

Yeah, true. That's the way http://www.wikipedia.org does it.

> Then again, I'm sure there are valid and common use cases for
> non-native language names, and including metadata may be a slippery
> slope, so I won't push the idea further.

I still like the idea. Maybe I can find a way to automatically update locale files at rails-i18n from cldr at some point. Or something. If you want to fork and do it manually, I'll pull.

> Thanks a lot for the feedback, Sven!

You're welcome. Thanks for the contributions!