language: Prevent data race while registering plural specs

[n10v]

See gohugoio/hugo#3971

[nicksnyder]

Why do you think that go-i18n should be responsible for protecting against this data race instead of the consumer of the library?

[n10v]

Why not?

[nicksnyder]

For the same reasons that map itself isn’t goroutine safe.

1. Everyone shouldn’t pay the cost of synchronization if they don’t need it.
2. You frequently need synchronization at a higher level anyway so doing synchronization at lower levels is unnecessary complexity and a waste of CPU.

Your Go program should load translations during its initialization.

More specifically, go-i18 was never designed to be goroutine safe (for the above reasons) and I would be surprised if this were the only change needed to make it completely goroutine safe. Making it partially goroutine safe is not intuitive.

I don’t know how Hugo is architected, but it isn’t clear to me that this change would solve your problem anyway. This change may solve the low level data race but it would not necessarily prevent you from reading from the translation store before all the data is writen (which is really what you should be enforcing) and go-i18 can’t really help you with that. This is what I meant by “synchronization at a higher level”.

go-i18n is just a nice wrapper around maps specifically for i18n. If you need synchronization then I think that belongs at the app layer.

[n10v]

Ok. You're right. I close it.