This could only happen if you update an old installation.
A completely new installation creates all the labels as set by the installation language.
In that state, switch to the different language, close MP3tag and delete all the files that store user-defined columns and labels.
MP3tag will then start with the set language.
After the initial installation all labels are treated as user-defined labels and cannot be translated.
The underlying problem is: how do you translate any user-defined label into any other language?
How do you treat labels that refer to standard fields but have their own wording?
As soon as you have a personalized installation (and that starts to live once you have chosen the initial way to install) the personalized data is not touched any more.
I would not call that a workaround but respectful treatment of the user input.
I understand that it has been discussed at least twice and that it has been graded as "no bug" in each case: /t/18800/1 /t/19284/1
The administrators of this forum grade the bug reports and I am no administrator.
Their decision was "no bug" and I simply supplied the service to make up for what you left out: the research as requested by the forum guidelines if there has already been a discussion on a particular topic.
Your picture shows edit-field labels resp. column names, which have been set up manually by the user.
Because Mp3tag does not translate any given user input into several languages, you have to do it for yourself, if you need it.
The screenshot in your initial posting shows additional Tags-fields in the tag-panel, which are in Lithuanian and you have marked with a red border.
These tag-fields are not a component of a new MP3Tag-Installation and therefore have been configured by the user in
Tools - > Options - > Tag-Panel
If you configure additional tag-fields for the tag-panel (as well as for the columns) you have to choose a tag-field and give this tag-field a name. This name is user-defined and no one than the user is able to change the name (translate).
That is not a speculation but a logic conclusion.
Do you see defined tag-fields there or not? This is easy to check.
A fresh complete new MP3Tag-installation (not if there are configuration files from a previous installtion) has no defined tag-fields there.
I can tell you that I change the language all the time from German to English and back, because sometimes I have to check the correct menu-items to aswer in english here.
All my tag-field-names but the self-defined change from one language to the other.
Addtional entries in the tag-menu I configured myself naturally keep the name.
Wow, this topic really went somewhere strange quickly. I'll try to clarify:
I didn't consider this a bug in the linked topics, but I've changed my mind. I think Mp3tag should at least translate the fields that are part of the standard installation and are not changed.
Two topics are mixed in those posts, which are
Mp3tag's language selection logic
Mp3tag doesn't offer language selection during installation anymore, because it's difficult to impossible (for me) to achieve this given the architecture of the used installation system and admin-eleveation during installation. Because of this, Mp3tag is trying to detect the user language and uses the user locale as its means to determine the language to be used in Mp3tag. For users with different Windows language / user local, this is sometimes surprising — and sometimes not.
I don't see this as a bug, but maybe this can be improved further on.
Mp3tag's behavior when switching languages
Mp3tag offers customization of file-list columns and tag-panel entries and comes with a default set of those. In the past, my thinking was, that I preferably don't mess around with those entries because they might be changed by the user. However, - and this is where I've changed my mind -, I think Mp3tag can detect which fields are changed and which are not, and auto-translate those unchanged fields. This comes with some implementation effort, but I think it's worth the effort given the amount of discussion and confusion which is otherwise produced.
Well, if this case should be true, then you did not apply a fresh installation of Mp3tag.
Anywhere in your user related Mp3tag appdata disk folder there might be some old file "usrfields.ini", which carries some user defined entries of foreign language.
Search the folder ... "%appdata%\Mp3tag\data"
Does that mean that Mp3Tag has a look at the tag-field itself, looks at the name of the tag-field and if this name is "original" changes it according to the language?
So you regard a special name for a tag-field in each language as original?
Are there "original" names beyond the predefined column- and tagpanel-view?
Yes. For the tag-panel fields I'd check the default ones (currently ALBUMARTIST, COMPOSER, and DISCNUMBER) and use the translated names for them on language change. Same applies to the columns of the file view.
I'm not sure, if I fully understand what you mean by "special name". I'd look at the internal representation which is the field name that is used internally (same as, e.g., in format strings) and use this one as a means for detecting "original" fields. Then compare the language-specific name of this default field (e.g., Kompozitorius for composer in Lithuanian) and only then auto-translate to the target language.
No. If you add a "real" user-defined entry to the Tag Panel, e.g., "Sortierung Interpret" for ARTISTSORT, Mp3tag would leave this untouched.