Language: preselect which languages users can choose from #129

New issue

Open

opened 2018-11-26 11:07:57 +00:00 by tammoterhark · 3 comments

tammoterhark commented

2018-11-26 11:07:57 +00:00

(Migrated from github.com)

In the admin user interface define place where complete language list can be subsetted into list with languages available for this site.

Example from Limesurvey

In the admin user interface define place where complete language list can be subsetted into list with languages available for this site. ![tools for research surveys 7](https://user-images.githubusercontent.com/6483317/49010541-e167a800-f173-11e8-9fb3-57212431be90.png) Example from Limesurvey

giplt commented

2018-11-26 19:30:21 +00:00

(Migrated from github.com)

This is related to issue #137

matthijskooijman commented

2019-12-09 12:19:35 +00:00

(Migrated from github.com)

A simpler version would be to just make a distinction in the language selection dropdown: First show languages that are currently in use, then a horizontal line or other separator, then all other languages.

Furthermore, it would be good to add a "Select language" or other dummy option at the top of the select, so you are actually forced to make a selection rather than automatically getting the aa language as currently when you ignore the dropdown entirely. Optionally, if only two languages are in use, you could preselect the "other" language already, which will likely what you want in most cases.

One related problem, that can probably be solved along with this issue, is that the language dropdown in the translation view currently shows all languages, except the current language (e.g. through where you reached the translation view). However, if multiple translations are already present, the dropdown will still show languages that already have a translation (and maybe the server-side handling code will even allow them and create duplicate translations, I haven't checked that).

I have worked on this for a bit, but struggled a bit with making an interface that is easy to use without becoming too complicated. Then, discussing this with @giplt, we considered an alternative: Always allow all languages, but make it a bit harder to pick a language that is not currently used yet. @giplt suggested a dropdown with currently used languages, and an explicit "Add new language" interface (that can be used by any user, not just admins). A simpler version would be to just make a distinction in the language selection dropdown: First show languages that are currently in use, then a horizontal line or other separator, then all other languages. Furthermore, it would be good to add a "Select language" or other dummy option at the top of the select, so you are actually forced to make a selection rather than automatically getting the `aa` language as currently when you ignore the dropdown entirely. Optionally, if only two languages are in use, you could preselect the "other" language already, which will likely what you want in most cases. One related problem, that can probably be solved along with this issue, is that the language dropdown in the translation view currently shows all languages, except the *current* language (e.g. through where you reached the translation view). However, if multiple translations are already present, the dropdown will still show languages that already have a translation (and maybe the server-side handling code will even allow them and create duplicate translations, I haven't checked that).

matthijskooijman commented

2019-12-09 12:26:43 +00:00

(Migrated from github.com)

I already looked at implementing the modified dropdown in the translation view, but to do that properly, I wanted to change languageOptionList to return an array of DomElements rather than a single string, but that required being able to modify the DOM of the HTMLForm after creating it, which turned out to be a bit tricky (and then I ran out of time). Maybe a lighter version would be to return an array of strings, so you can reorder them as needed (and insert additional separators etc.), but still insert them into the HTML string before creating the HTMLForm.

I already looked at implementing the modified dropdown in the translation view, but to do that properly, I wanted to change `languageOptionList` to return an array of DomElements rather than a single string, but that required being able to modify the DOM of the HTMLForm after creating it, which turned out to be a bit tricky (and then I ran out of time). Maybe a lighter version would be to return an array of strings, so you can reorder them as needed (and insert additional separators etc.), but still insert them into the HTML string before creating the HTMLForm.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

harmen/hypha#129

No description provided.

Rows
Columns