Localization Support

[jyhi]

So far all the descs are in English, so when an application is displaying the data it still prints English strings, regardless of the application's l10n status (e.g. apt-gen-list is 100% localized to zh_CN).

Localization support also helps DeployKit, who has supported its own localization scheme in recipe.json, which is put on the main repository (repo.aosc.io). Now DeployKit plans to read these data as an alternative if they are found in the local system (and it should be installed on LiveKit), but localization is lost.

[jyhi]

In the DeployKit recipe.json I designed the localization strings as a special key: key@loc. An example:

"foo@zh-cn": "那只敏捷的狐狸跃过了那只懒惰的狗"

To read YAML from Vala I wrote yaml-vala, the binding template of libyaml for Vala. During the process of writing the binding I was aware that YAML has a pretty powerful grammar, so I believe there should be a YAML way to do this. Any suggestions?

[liushuyu]

To read YAML from Vala I wrote yaml-vala, the binding template of libyaml for Vala. During the process of writing the binding I was aware that YAML has a pretty powerful grammar, so I believe there should be a YAML way to do this. Any suggestions?

Why not using gettext?

Also, it would be better to structure the language file like:

"zh_CN":
{
    "foo": "我能吞下玻璃而不伤身体"
}

Translate to YAML, it would be:

- zh_CN
    - foo: 我能吞下玻璃而不伤身体

[jyhi]

@liushuyu

Why not using gettext?

I don't think it's appropriate. gettext is for localizing applications, and aosc-os-repository-data is a piece of separated data.

Also, it would be better to structure the language file like:

This basically breaks semantics, although this is possible:

"foo": "The quick brown fox jumps over the lazy dog.",
"foo-l10n": {
  "zh_CN": "那只敏捷的狐狸跃过了那只懒惰的狗"
}

Of course recipe.json is subject to change.

[liushuyu]

This basically breaks semantics, although this is possible:

Or you can learn from some reactive web application frameworks, using string keys to index the translations: instead of using the actual string in the definition file, we use a message ID, then in the designated language file, we define the actual strings there.

"components": ["foo", "bar"]

In another file:

"en": {
    "component.foo": "The quick brown fox jumps over the lazy dog."
},
"zh_CN": {
    "component.foo": "那只敏捷的狐狸跃过了那只懒惰的狗"
}

Something like that

[jyhi]

Or you can learn from some reactive web application frameworks

Yes, and design problems of recipe.json may go to DeployKit issues. Now I'd like to seek l10n support in aosc-os-repository-data. This not only benefits DeployKit but also apt-gen-list as well.

[MingcongBai]

@LionNatsu Mind chiming in here?