Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

i18n: Allow custom language codes #3971

Closed

Conversation

KevinGimbel
Copy link
Contributor

This PR uses the new RegisterPluralSpec function from go-i18n to register all languages defined. Previously only language codes available within the Unicode CLDR standard could be defined.

Use the new `RegisterPluralSpec` function to register all defined
languages. This allows the usage of language identifiers which are not
part of the Unicode CLDR standard.

See gohugoio#3564
@CLAassistant
Copy link

CLAassistant commented Oct 15, 2017

CLA assistant check
All committers have signed the CLA.

@KevinGimbel
Copy link
Contributor Author

KevinGimbel commented Oct 15, 2017

Interesting. Travis fails on mage -v check but this did not fail on my machine. I'll take a look at it.

It now fails on my machine, too. I'll look into it.

@KevinGimbel
Copy link
Contributor Author

@BoGeM Could you help me with this? I added a test for "dk.toml" to the i18n_test.go file, see https://github.com/gohugoio/hugo/pull/3971/files#diff-e0ea71d98579d0c18004dbb09fdfaff7R142

If I run mage test the test passes, which means the previously unsupported language "dk" can now be loaded.

However, with the new RegisterPluralSpec function in translationProvider.go I get a data race error. I don't know how to debug this - could you give me a hint?

Copy link
Contributor

@n10v n10v left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but with some correctives below.
Data race is an issue of i18n library. I will make a PR for it.


for file := range test.data {
id := strings.Split(file, ".toml")
ids = append(ids, id[0])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use this:

id : = strings.TrimSuffix(file, ".toml")
ids = append(ids, id)

@@ -37,6 +38,8 @@ func (tp *TranslationProvider) Update(d *deps.Deps) error {
dir := d.PathSpec.AbsPathify(d.Cfg.GetString("i18nDir"))
sp := source.NewSourceSpec(d.Cfg, d.Fs)
sources := []source.Input{sp.NewFilesystem(dir)}
ps := &language.PluralSpec{}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Move this just before the 60th line.

@@ -37,6 +38,8 @@ func (tp *TranslationProvider) Update(d *deps.Deps) error {
dir := d.PathSpec.AbsPathify(d.Cfg.GetString("i18nDir"))
sp := source.NewSourceSpec(d.Cfg, d.Fs)
sources := []source.Input{sp.NewFilesystem(dir)}
ps := &language.PluralSpec{}
langs := []string{}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Move this just before the 54th line.

@@ -50,6 +53,14 @@ func (tp *TranslationProvider) Update(d *deps.Deps) error {

for _, currentSource := range sources {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a comment here that we should plural specs of languages to prevent the error of using custom language codes.
And add a link to #3564 too.

@n10v
Copy link
Contributor

n10v commented Oct 30, 2017

See nicksnyder/go-i18n#81

@KevinGimbel
Copy link
Contributor Author

KevinGimbel commented Oct 31, 2017

@BoGeM I made the following changes:

  • Move variable initialization in translationProvider.go
  • Add comment about language specs with a reference to the original issue
  • Change the language ID parsing from string.Split to string.TrimSuffix

langs = append(langs, r.BaseFileName())
}
}
// we need to register all language codes as "plural spec" to prevent errors
Copy link
Contributor

@n10v n10v Oct 31, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add dots at the end of sentences and please start sentences with capital letters.

@KevinGimbel
Copy link
Contributor Author

@BoGeM I capitalized the "w" in "We" and added a dot at the end of the sentence.

@n10v
Copy link
Contributor

n10v commented Nov 2, 2017

To prevent data race try to do the following:

  1. Add sync.Mutex to translationProvider:
// i18n/translationProvider.go

// TranslationProvider provides translation handling, i.e. loading
// of bundles etc.
type TranslationProvider struct {
    t Translator
    sync.Mutex // <--
}
  1. Use mutex when registering plural spec:
// i18n/translationProvider.go

ps := &language.PluralSpec{}
tp.Lock()
language.RegisterPluralSpec(langs, ps)
tp.Unlock()

Actually I'm not sure, if it will help. But anyway let me know about the result of tests.

@bep
Copy link
Member

bep commented Nov 2, 2017

Actually I'm not sure, if it will help. But anyway let me know about the result of tests.

It will not help. You cannot just lock the write -- this is a read/write map race. Wasn't this fixed upstream? If so, you need to update your dependencies.

@KevinGimbel
Copy link
Contributor Author

@bep the fix from @BoGeM was rejected upstream nicksnyder/go-i18n#81

@n10v
Copy link
Contributor

n10v commented Nov 2, 2017

@bep the fix from @BoGeM was rejected upstream nicksnyder/go-i18n#81

Exactly. And I find @nicksnyder's arguments convincing.

@bep
Copy link
Member

bep commented Nov 2, 2017

OK, but my point still holds. You cannot just lock the writer side of it.

@n10v
Copy link
Contributor

n10v commented Nov 2, 2017

@bep how can we add locking for read operations? Can you help please?

@bep
Copy link
Member

bep commented Nov 2, 2017

I will look. Ideally we would do the RegisterPluralSpec before we start any processing, but this is a global used by every site, so I think concurrency is hard to avoid. But I will have a look.

@bep
Copy link
Member

bep commented Nov 2, 2017

See nicksnyder/go-i18n#82

@bep
Copy link
Member

bep commented Nov 2, 2017

As to "getting this one working", all the races seems to be in the Update method, so this should work:

bep@96ed4f5

@KevinGimbel
Copy link
Contributor Author

@bep thanks a lot for getting into this, I was completely lost unfortunately!

Should I add the code to my PR or will you merge your branch?

@bep
Copy link
Member

bep commented Nov 2, 2017

Just copy and paste my code.

@KevinGimbel
Copy link
Contributor Author

@bep I added your changes to my PR. mage hugoRace no longer fail on my machine, but mage check still fails.

@bep
Copy link
Member

bep commented Nov 3, 2017

@KevinGimbel I will fix/merge this tomorrow. And for the long run, I will see if I can create a PR for the go-18n lib ... some time.

@bep
Copy link
Member

bep commented Nov 4, 2017

#4049 replaces and includes this

@bep bep closed this Nov 4, 2017
@github-actions
Copy link

github-actions bot commented Feb 8, 2022

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 8, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants