Description of problem: Zanata takes an "opt-in" approach to supported languages. This is not optimal as: - "Someone" of admin status has to add the language - Users have to request the language - User has to have some idea that the language is not supported, and needs to be requested The other part of the problem is the "enabled by default" feature, which in one way or another puts a burden on someone, in that they - have to remove the languages they never wanted - would have to scan the list to make sure their chosen languages are there, before adding it - already added languages won't show in a search. This would be confusing if the language has not been added. Simply put, all languages should be "added". Zanata could then present to the user on project language selection, something like: - Their chosen languages list - A search bar to locate a specific language - a full list of languages ordered by alphabetical, or popularity, or some other favourable sort This would greatly streamline the process. Version-Release number of selected component (if applicable): 3.5
Yep. I'll work on a new interface… someday.
(In reply to Damian Jansen from comment #0) > Description of problem: > Zanata takes an "opt-in" approach to supported languages. This is not > optimal as: > - "Someone" of admin status has to add the language > - Users have to request the language > - User has to have some idea that the language is not supported, and needs > to be requested According to Bug 1128967, some translator does not like the idea of, say sv_FI to be included unless someone actually ask for it. > Simply put, all languages should be "added". Zanata could then present to > the user on project language selection, something like: > - Their chosen languages list > - A search bar to locate a specific language > - a full list of languages ordered by alphabetical, or popularity, or some > other favourable sort > > This would greatly streamline the process. I don't think it is practical to ad can add "all" the languages that may exist. For example, should you add zh_AU by default? Also in translate.zanata.org we have 3 languages groups that basically all means the simplified Chinese in China. zh-Hans, zh-CN, and zh-Hans-CN. Wikipedia use the zh-Hans, and zh-Hans-CN, yet *nix use zh_CN solely. We did have all 3, but theirs translation memory cannot be shared, it also confuse the new comers for which language team they should join. We can, however, provide some default sets like "Fedora" for Fedora supported languages and "Wikipedia" for wikipedia supported languags. It will much easier for project maintainers to choose from those default set.
To make this workable for Zanata developers, I suggest we change the title to "RFE: project maintainer can select "Fedora" to select Fedora supported locales". We can later on add the support of some thing like "Wikipedia support locales" in other bug.
Wait what? This is horrible, no! There are 2 thing we need to do: 1. Make all languages available to the "Server". 2. Don't add any languages to a project by default. If we have language sets they should be organisation based (which we don't have yet) and then each project for that organisation can choose to add that organisations default languages.
(In reply to Luke Brooker from comment #4) > Wait what? > > This is horrible, no! > > There are 2 thing we need to do: > > 1. Make all languages available to the "Server". Where do you get the list of all languages? Starting from Fedora language list is a good choice. Yet I can see there is quite likely you will need the capability to add new language from time to time. > > 2. Don't add any languages to a project by default. > > If we have language sets they should be organisation based (which we don't > have yet) and then each project for that organisation can choose to add that > organisations default languages. In translate.zanata.org and translate.jboss.org, none of the users are in any organization, making them all assigned to organization "default" won't solve the problem. And even if we have the organization "Red Hat", RHEL team and portal team still required different sets of languages. I really don't think it worth the effort to create sub-organizations. Not to mention that organization Fedora and RHEL might share the same set of languages. On the other hands, making the default set independent from organization have following benefit: 1) Different organization can share langauge team 2) No sub-organization required. 3) So this high severity feature does not need to depend on non-existed organization feature.
(In reply to Damian Jansen from comment #0) Actually there are 3 bugs. > Description of problem: > Zanata takes an "opt-in" approach to supported languages. This is not > optimal as: > - "Someone" of admin status has to add the language > - Users have to request the language > - User has to have some idea that the language is not supported, and needs > to be requested If you mean that you want to remove the capability of adding new languages, please don't, otherwise Zanata won't be able to handle the cases like new languages, and someone wants to translate rarely use languages. However, if what you mean is you want Zanata to pre-set the frequently used languages, I totally agree. > The other part of the problem is the "enabled by default" feature, which in > one way or another puts a burden on someone, in that they > - have to remove the languages they never wanted > - would have to scan the list to make sure their chosen languages are there, > before adding it - already added languages won't show in a search. This > would be confusing if the language has not been added. "Enabled by default" is actually the inverse of "Source Language", We cannot really remove en-US due to Bug 836408, yet it should not be shown as translatable in most of cases. The confusion cause by "Enabled by default" can actually be solved by Bug 1155462. > Simply put, all languages should be "added". Zanata could then present to > the user on project language selection, something like: > - Their chosen languages list > - A search bar to locate a specific language > - a full list of languages ordered by alphabetical, or popularity, or some > other favourable sort > > This would greatly streamline the process. > In addition, it would even nicer that project maintainer can choose the recommended language sets. User story: As a Fedora package developer, I would like to select Fedora supported locales by one click, so I can quick done the project setting.
The original title "RFE: Admin language management is poor and generally unnecessary" is poor and generally misleading, as: 1) it mistakenly implies that "Manage Languages" feature should be removed. 2) it does not clearly state the purpose and direction of this bug. I think the following title is more appropriate: RFE: Streamline the language selection for project maintainer
Dean, you've wholly misinterpreted this bug. Please stop changing the title to what you think it means. This is not about projects, this is about the fact that having a admin managed subset of the functionally supported languages is unnecessary and adds overhead to the administrator responsibilities. I'm not implying that the manage languages feature be removed - I'm stating it specifically! Disabling someone's chosen language or forcing an unwanted language choice on someone originates from this pointless exercise. The only reason I can see for managing languages is to know what languages can be used and finding out why a certain one cannot be. Or, I suppose the other thought is the ability to add a language that doesn't exist, like Klingon or Divinian. However custom languages should sit on top of the world known set that is - as I said - always available.
Migrated; check JIRA for bug status: http://zanata.atlassian.net/browse/ZNTA-366