-
New Feature
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
None
Just like instruments, I think it would make sense to have languages as entities instead of attributes.
1. Languages can have different names, not just in different languages, but also in the same language. For example, the language West Frisian is officially known as Westerlauwers Fries in Dutch, but everyone just calls it Fries, although that really is the name of the language family. An entity with aliases would make searching for either name a possibility. It would also make it possible to search for a language in a different language: A Japanese user with a French release in hand with track titles written in "Frison occidental" would be able to find the right language for his release.
2. Different languages can share the same name, but that can be solved with disambiguation comments.
3. ISO-codes could be implemented as attributes.
4. Languages are often grouped in families, but our current system doesn't list that information, and I think that would be way out of scope for MusicBrainz anyway, so I would suggest not implementing relationships between languages. Let's keep things simple and avoid LanguageBrainz. 
5. Instrument-URL relationships could be established, like for Wikidata and Ethnologue.
6. It would be easier to get lists of releases, works etc. in a certain language, because that would be displayed on the language page. I think this would be interesting to have this information in a more accessible format.
- is related to
-
-
- Open
-
[MBS-9667] Make languages entities
You guys probably aren’t looking for more work to do and complex schema changes to boot. I also don’t know how much more upkeep this new system would require, as compared to the current implementation of languages. But I do think having languages would offer clear advantages as described above.
Languages are not quite in the scope of MusicBrainz, it just relies on external references, that is, ISO-639-3 for now. I’m not sure it is necessary to carry the burden of a new entity type to have all the features you listed.
You compared it to instruments, but this is closer by the scope of MusicBrainz. New music instruments are being invented every day and some members of the community shown interest into having individual instruments like individual organs. That justifies having instrument entity type which is versatile and allows for some (not all) of the features you listed. It still has some issues (localization and aliases are not synchronized, family is at top-level only…) that will require major changes.
A better comparison would be with Area entity type, which is out of the scope of MusicBrainz. Wikidata might be considered as a replacement, since it is already linked to from (every?) area.
More feasible short-term improvement would be to allow free text search in the language selector.