Spec: Define whether <languages> should list en_US explicitly

[pwithnall]

Almost all applications (which use gettext, at least) are written with their C (untranslated) locale in en_US. This means that they never have an explicit en_US translation, but are always 100% translated to en_US.

Should the <languages> element list en_US explicitly, in which case it should probably be injected by the appstream XML generator?

Or should the spec say that the application’s C locale is never listed as a <lang> element, and should be assumed to be en_US?

If we go with the second option, perhaps the assumption about the C locale being en_US could be overrideable (in the few cases where an application is written in something other than US English by default) by setting an attribute like <languages default-language="es_ES"> and defining that language as 100% translated.

I can put together a merge request to update the specification either way, but need to know what approach would be preferable 🙂

[hughsie]

My assumption was always that the default language was C == en_US.

[pwithnall]

Yeah, and that’s a good assumption, but I can’t find anything in gettext which actually requires C == en_US. I might be missing it, or it might be the case that there’s a handful of apps out there where C is French or German or whatever.

[ximion]

I actually came across a project where C was German, and two where C was Mandarin and Russian (which was horrendous for collaboration...), so I think the AppStream spec shouldn't blindly encode C == en_US.
I wonder if we can do some heuristics here... Otherwise having <languages default="es_ES"> looks like a good idea, and also follows AppStream's "explicit is better than implicit" rule (Is default a good name? Maybe template or source is better?). If that property isn't there, we'll assume en_US as default, and libappstream could even synthesize a 100% translation entry for that language in those cases, which would solve this issue and be fully backwards compatible.
I guess for 99.9% of all projects, assuming en_US as template language is the right thing to do.

[pwithnall]

Thanks for your thoughts @ximion! I’ll try and put together a draft merge request for this (and my other recent issues) in September, once I have a bit of headspace from the GNOME release.

[pwithnall]

I’ve put some proposed spec changes together at #351 for discussion. I don’t think they should be merged until libappstream and appstream-compose have been changed to support the new functionality, but I didn’t want to work on that until the spec changes are largely agreed.