View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0017117||phpList 3 application||Internationalization (l18n)||public||18-03-14 11:37||13-02-19 12:38|
|Priority||normal||Severity||feature||Reproducibility||have not tried|
|Summary||0017117: spageedit - Dropdown of frontend languages to list the language in the language|
|Description||I think that will be great to name files with frontend translations in original language. Because of that name is displayed on EDIT A SUBSCRIBE PAGE (spageedit).|
|Steps To Reproduce||Go to /lists/admin/?page=spageedit|
Select an exisiting page or create new subscription page
Open dropdown menu for "Language file to use"
|Additional Information||Screenshots in attachment|
|Tags||No tags attached.|
I think we should resolve this similarly to the backend translation files, in that there's "meta file" with the description.
Doing it by renaming the file in the language has too many OS dependencies.
Actually, thinking about this a bit more, this is a bit more complicated than initially thought.
Imagine you're an English speaking person who doesn't know any other languages (which is fairly common). You are asked by your boss (who possibly speaks more languages) to set up subscribe pages in English, French, Finnish and Japanese.
You would need to know what Finnish is in Finnish and Japanese in Japanese. That is not going to work.
Instead, the dropdown should populate with the names of the languages in the language of the admin. But that's a second dimension in the process.
So, really what we need is a matrix mapping of all language names in all languages for this to work.
> Instead, the dropdown should populate with the names of the languages in the language of the admin. But that's a second dimension in the process.
I agree that what is proposed is the best option for usability. However, I think that the effort required to adopt a new matrix system, vs the benefit to those people who seek to use languages who's native name they do not know, is not proportionate. Therefore this improvement would be valuable, but should not be prioritised for a particular release.