Feature request: respect custom sorting of usedefined tag value lists

While you can enter yor custom values into the lists for each tag in any order you want, it will always autosort the values alphabeticaly in the tagpanel.

If i wanted them alphabeticaly, i would make the list alphabeticaly!
But when you organize the list in a priority order, with the most used values on top, mp3tag will always destroy your order and shove them down.
For example: For the "language" tag i put

1 English
2 Finnish
3 German
4 Instrumental
5 Norwegian
6 Swedish
7 Icelandic
8+ all other commonly used languages sorted alphabeticaly

Yet in the tag panel, i have to search for these in my collection most common languages, because mp3tag thinks they better be mixed into the lower group.
And the same goes for 7 other tags that i would like to define the order myself.

If you write that string to the language field then you leave the boundaries of the ID3 standard which defines this field as:
"The three byte language field is used to describe the language of the frame's content, according to ISO-639-2."
The proper code for "German" would be "deu" according to that standard.

vorbis comments dont care

Yes, this is by design — it's also with track titles, artist names, and other fields when you select multiple files.

I currently have no plans in changing this, although I understand that it would be useful to you.

You're probably aware that you can type the first letters and the field tries to auto-complete. It's not what you've asked for, but I wanted to mention this anyway because it might speed things up a little.

Ok, forgot about the typing, that may help a bit...

PS: Since i kinda omitted it in the first post, i wasnt asking for a complete change of the behavior, more for a little tick box "sort alphabet/numericaly <-> sort by list order" in the user defined list setup menue. Ubiquitously changeing it for all fields including track numbers would be insane.

Yes, I understood it like that. The Tag Panel configuration (including custom values) is already peak complexity for some if not many users, so I'm currently hesitant to add more options there.