FR: add languages
DeusFigendi opened this issue · comments
I believe it would be an interesting information for people searching for an instance in a federated network to know which languages a server supports.
And I'd say there are two intetesting points:
- Which languages does the admin/team speak. Which one is ptefered (native language)
- Which languages are supported by the UI
I see two ways to represent this data:
"languages": { "team":[array of lang-codes],"UI": [array of lang-codes]}
But I would preffer this:
"team": {"languages": [array of lang-codes]},
"UI":{"languages": [array of lang-codes]}
I preffer this because I think it is more likely to provide more information about tze admin/team/support/UI but about languages. For example size of the team or podmins handle or UI-color-themes or whatever. Even IF there is an UI. (I'd say relays don't have one).
The names of the keys don't have to be team and UI and languages. It could also be support or admin instead of team and interface for UI and ui_lang instead of languages.
To represent the prefferation of a language there could be a qualifier like q=0.8 but to keep it simple I'd say the preferencr could be represented by the order of languages.
I don't know if this really needs to go to the spec here, since this probably would be optional anyway (I think we want to make implementations as easy as possible), it maybe also could go to the dynamic metadata field. diaspora already added the adminAccount there, this could maybe be combined with the podmin language. And yes, I think podmin language is a useful thing that could be added.
But I'm not sure about "UI"-languages. This would be the same for every pod (maybe there is a language more in a newer version, but other pods would get the new language too a bit later). Also what would be the criteria to add a language there? Most of the languages in diaspora are only partly complete, which would you add to the list? Also you can simply check if diaspora supports your language when you go to the start-page or registration-page, it tries to use the languages you configured in your browser. When you see it in your language, then you know that at least these pages are translated. When you want to see which languages are how much translated, you can only see this on WebTranslateIt.
Sure, the UI languages would be different for different softwares, but I don't know if this needs to be in the nodeinfo for that. And I don't know if you select your software based if it is available in your languages.
I tend to disagree…
I don't know if this really needs to go to the spec here, since this probably would be optional anyway (I think we want to make implementations as easy as possible), it maybe also could go to the dynamic metadata field.
Yes and no. Of corse it should be optional. There might be implementations of nodeinfo or any distributed social network protocol which is complete language independend. I'd say social relay is close to this.
But I also think it should be standardized in some way so these data are always presented in the same form and comparable and easy to implement for a client. So yes it could go to the metadata field but the metadata field is defined with
Clients should not rely on any specific key present.
And I think clients should be able to relay on the key if it is present.
But I'm not sure about "UI"-languages. This would be the same for every pod (…) Sure, the UI languages would be different for different softwares, but I don't know if this needs to be in the nodeinfo for that.
No this is wrong. For example in diaspora* some pods host a xx-moo language which is... German with some cowish jokes. But not all pods have this. So yes in general this is depending on the software (and software version) but in the end podmins can create new UI-language or delete some for whatever reason. Maybe they only want users speaking a special language or they want clear error messages always in English or… well I don't know.
Also what would be the criteria to add a language there? Most of the languages in diaspora are only partly complete, which would you add to the list?
Well that is a little tricky but I'd say that's just the decision of the podmin and/or the software developer. It's kinda binary decision: The language support is enough to be counted as "supported" or it isn't. So I guess the translator or the software developer would decide if a language is complete enough and a podmin might change it if she disagrees.
Also you can simply check if diaspora supports your language when you go to the start-page or registration-page, it tries to use the languages you configured in your browser.
Sure, or I can read the sources. But usually nodeinfo isn't made for humans, it's made for mashines isn't it? So this is not for a user to find out what languages are supported it is for services like podupti.me and similar.
I was inspired by Join Mastodon they filter mastodon instances by language (whereever the information comes from). And it would be a pitty if someone who writes something similar has to write a scraper for every software to find out which languages are supported.
When you want to see which languages are how much translated, you can only see this on WebTranslateIt.
Yes, I want to know that and I want to know that for every software supporting nodeinfo.
And I don't know if you select your software based if it is available in your languages.
Sure I do. I would not use a software that doesn't support a language I understand if it is somehow language depended. Would you use a software which is only available in Brazilian Portuguese and a pirate version of dutch?
And I think clients should be able to relay on the key if it is present.
Ok, I see that, so I agree it could have advantages to specify how it should look like if it is present.
Howevery I still think it should only be used for podmin languages (which is important when you want to contact your podmin). I don't think a user would search any "joke-languages", and even if, the podmin-language should be the important part (and I don't think you find a server where the podmin speaks cowish).
And I also don't see why podmins should disable any languages despite of providing a bad UX for their users (and it could also really break things when you don't know what you're doing), so I don't think it would be a good or useful thing to provide settings for podmins to select UI languages (they could still modify the code, but they hopefully know what they do then).
Yes, I want to know that and I want to know that for every software supporting nodeinfo.
Then you could just parse that once per software and keep in your database (even including the percentage if that is available for all project, but it would be difficult to export that via nodeinfo).
Would you use a software which is only available in Brazilian Portuguese and a pirate version of dutch?
All of the currently existing software support at least english, so I would rather select which software fits my needs the most not if it supports my language. And it still is difficult to create a list which languages are really supported, because it could be "supported", but only 5% translated, so when you don't understand english it wouldn't help at all.
And when you want to create something like "join mastodon" you should keep it simple, and selecting how complete a UI should be translated in which language is probably already too complicated. While a podmin language could be an important information.
You maybe could display a little warning if the selected software doesn't support the language in the UI or only a low percentage, but for that it is enough to collect that data once per software. But the important selector should be the podmin language.
To be honest @SuperTux88 : I believe you're thinking a little in a diaspora*-box.
I don't think a user would search any "joke-languages"
Yes, you're totally right that was a bad example. For most use cases I had in mind this type of languages isn't relevant.
Yes, I want to know that and I want to know that for every software supporting nodeinfo.
Then you could just parse that once per software and keep in your database
No I can't. One could do it if one knows every kind and type of software supporting nodeinfo and is willing to write a new scraper/parser/table whenever a new one pops up. If today someone starts any type of project where these information is usefull and she finds this repo or http://nodeinfo.diaspora.software/ it says:
So far integration of this standard exist for the following softwares: diaspora* Friendica
Okay so she has to check exact two softwares right? No it isn't. It is just normal that such types of documents date out. And so would a database or whatever that keeps the information which software is available in which language. If a new software appears the database is outdated.
(even including the percentage if that is available for all project, but it would be difficult to export that via nodeinfo).
Yea, I thought about something similar, you could provide more information about every language if you decide to make objects instead of simple strings. But I would also prefer to keep it simple. And use ['en-US','de-CH'] and not something like
[{'code':'en-US','finished':'1','prefered':'yes','name':'english'},
{'code':'de-CH','finished':'0.98','prefered':'yes','name':'deutsch'},
{'code':'la-VA','finished':'0.1','prefered':'no','name':'latinum'}]
Yes, this would be possible but I think it's no good idea XD
All of the currently existing software support at least english, so I would rather select which software fits my needs the most not if it supports my language.
How do you know that. I am assuming by "all currently existing software" you mean those supporting the nodeinfo-standard. But you cannot know which or how many or what type of software exists. Except you think the list "diaspora*, Friendica" is complete.
So one: You think every software out there supports english but you cannot know!
And second: I tried to show you the perspective of someone who doesn't speak english. This is the more important part. There are people who speak polish and only polish. They cannot choose from all the software just by their needs. Or they don't want to because it's to difficult to them to use english software while they want to relax (or be sure what they're doing).
And it still is difficult to create a list which languages are really supported, because it could be "supported", but only 5% translated, so when you don't understand english it wouldn't help at all.
Yea, a 5% -language I would assume to be not supported. This decission should be done by the translator, developer or podmin or all of them.
Maybe another paragraph when I come home this afternoon :D
So, work is over XD
I just wanted to add this: I would be okay if @jhass decides not to add the UI-language while I still see no downsides if it is optional. You are also right, people can put such information into the fluid metadata field without touching this specification it's just not that useful in that case.
But I have a feeling that all your arguments are red herrings and you have some other motive why you dislike the idea. Maybe you don't know how to transfer this information from WebTranslateIt into such a document for diaspora*. Or you have a feeling that nodeinfo -documents shouldn't be too big (such a list would be a few bytes…). I don't know.
But all your arguments are somehow centered on diaspora* or on a status quo where no new software will ever add this standard. But in fact this isn't limited to a handfull half a dozen of softwares (like: diaspora* Friendica, SocialHome, Hubzilla, redMatrix, socialRelay) it isn't even limited to the diaspora*-protocol. It is for
exposing metadata about a server running one of the distributed social networks
distributed social networks like GNUsocial for example.
Yes, I'm writing this mainly as diaspora developer.
So far integration of this standard exist for the following softwares: diaspora* Friendica
Oh, I think Hubzilla and GangGo should be added to this list, because I just checked and they support a valid 2.0 implementation now 🎉
Yea, a 5% -language I would assume to be not supported. This decission should be done by the translator, developer or podmin or all of them.
Yes, but who decides which languages should be listed? As a developer I can't, because I don't understand these languages and can't check how correct and up-to-date translations are (besides from the percent value on), and as a podmin I don't even want to validate which translations are complete enough. And translators could add the language when they think it's complete enough, but who checks that it is removed again once the translators aren't active for this language anymore?
But since this is an optional field anyway, I (as a diaspora developer) would vote against implementing a UI-language-list in diaspora, because it simply help something. You can either create a simple list of languages, but then you don't have any information of how complete/correct/up-to-date it is, or you can create a complicated collection which is harder to implement and only over-complicates the whole thing but doesn't help the end user either.
you have some other motive why you dislike the idea.
I don't dislike the complete idea, I think adding the podmin language is a really great idea and important when choosing a pod and it's easy for a podmin to provide a list in which languages they are able to provide support. And I also agree that it's probably useful to specify in which format the language-list should be.
But I dislike the idea of the UI-language list, because it's really complex to provide useful information how much which language is supported in the UI (so I don't expect it to be specified that way because probably nobody would implement it that way) and it would be difficult to create a UI that is easy for the end-user to use this complex information. And a simple list of "this languages are present in the UI" doesn't help at all, when it means "it's maybe complete or only 5%, nobody knows". And even when a software would only add languages which are translated at least 50%, it wouldn't help when another software just adds all languages that are available. When the one is translated 40% (which is below 50%) in your selected language, and the other is translated 5%, the 40% software would be displayed with "it doesn't support your language" and the 5% software would be "it supports your language" (which I think would be really unhelpful for the end-user), and how would you display a software where this optional field is missing?
That's why I said: When you want reliable UI-language information, you need to collect them yourself, for each software and for each software in a similar way (so you filter languages which are below 50% yourself). Sure, that would be more work for you (or the person writing a software which would need this information), and it would be manual work every time you add support for a new software, but I think only then you can make the most out of this information and rely on it.
it isn't even limited to the diaspora*-protocol.
I didn't say that and I even contributed to design the 2.0 version which makes it better accessible for others to implement it in their software. I would like it when others would implement it (unrelated to the diaspora protocol or software).
This is my personal opinion (mainly from the point of view of a diaspora developer and diaspora podmin), I have no idea if and how other software would create and maintain a UI-languages list (but I think that would be important to know when you decide in which format you want to have this list).