-
-
Notifications
You must be signed in to change notification settings - Fork 7.5k
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
Add TOML support for language files #2577
Comments
Why is this an upstream issue? What's missing? |
It is maybe more clear now. The snyder lib does the parsing and currently only supports JSON and YAML. |
The question is, which structures should be used. I mean, there are no anonymous tables in TOML and it should be implemented in another way. For example, how could be written following structures in TOML? [
{
"id": "settings_title",
"translation": "Settings"
}
] [
{
"id": "d_days",
"translation": {
"one": "{{.Count}} day",
"other": "{{.Count}} days"
}
}
] Like this? [[Translations]]
id = "settings_title"
translation = "Settings" [[Translations]]
id = "d_days"
[[Translations.translation]]
one = "{{.Count}} day"
other = "{{.Count}} days" IMO YAML is more convenient for these things |
[[d_days]]
one = "{{.Count}} day"
other = "{{.Count}} days"
[[string_id_2]]
translation = "Some other translation" go-i18n's file format is probably an attempt of future-proofing, making it more complex than it should. If With that in mind, we could also maybe create some support for My main issue about Maybe @nicksnyder could chime in with his thoughts on this. |
I think, the adapter is the best option for hugo now. I will try to implement it if there will be no more ideas |
go-i18n's file format is an attempt to match the data that it actually needs. Each translation object has an id and either one translation (non-plural form) or multiple translations (plural form).
It can, so you can choose any format and inject translations as you see fit: If you prefer a flatter format I would recommend treating non-plural forms exactly the same:
If you need to differentiate between a plural and non-plural form (the The If there is general agreement that a flatter format would be better (even in JSON and YAML) then I am open to changing go-i18n. |
@nicksnyder but support for TOML will break all existing API of |
We have no real rush; @nicksnyder is right about the translation workflows, and we don't want to add additional glue code in Hugo if we don't really have to. I'll create an issue on the go-i18n tomorrow where we can continue this discussion. A flattening of the data format would be breaking, but it should be fairly easy to support both in a grace period. |
It doesn't need to. We can support a new format without dropping support for the old format. |
Fixes nicksnyder#61 Updates gohugoio/hugo#3200 Updates gohugoio/hugo#2577
Fixes nicksnyder#61 Updates gohugoio/hugo#3200 Updates gohugoio/hugo#2577
Fixes nicksnyder#61 Updates gohugoio/hugo#3200 Updates gohugoio/hugo#2577
Fixes nicksnyder#61 Updates gohugoio/hugo#3200 Updates gohugoio/hugo#2577
Fixes nicksnyder#61 Updates gohugoio/hugo#3200 Updates gohugoio/hugo#2577
Fixes nicksnyder#61 Updates gohugoio/hugo#3200 Updates gohugoio/hugo#2577
Fixes nicksnyder#61 Updates gohugoio/hugo#3200 Updates gohugoio/hugo#2577
Fixes nicksnyder#61 Updates gohugoio/hugo#3200 Updates gohugoio/hugo#2577
Fixes nicksnyder#61 Updates gohugoio/hugo#3200 Updates gohugoio/hugo#2577
Fixes #61 Updates gohugoio/hugo#3200 Updates gohugoio/hugo#2577
go-i18n 1.8 now supports TOML and a flatter file format Thanks @BoGeM ! |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Doing this in YAML is frustration galore.
EDIT: https://github.com/nicksnyder/go-i18n
The text was updated successfully, but these errors were encountered: