I'm experimenting with a dedicated
localizations object in the
.settings file, which lists all languages with localizations, where the individual localization items reference the
key that is used at the control definition.
"title": "Test Settings",
"title": "Something to choose from",
"description": "Select the preferred item",
"default": "Item 1"
"title": "Something to check",
"description": "Check to enable",
"title": "Test Einstellungen"
"title": "Etwas zur Auswahl",
"description": "Wählen Sie den gewünschten Eintrag"
"title": "Etwas zum Abhaken",
"description": "Häkchen setzen zum Aktivieren"
Please note that localization items are optional and are referenced using the
key from the individual items in the
settings definition. The window title is referenced using the root
key from the
The language keys are using the ISO-639-1 language code.
Localization of Tag Source configuration settings is now available with Mp3tag v3.21i and Mp3tag for Mac v1.8.4.
Thanks for that. I don't have much time to get the scripts updated but when I have them done I'll send them for testing to you. Esp for the mac version as I cannot test that.
I have to admit that I'm one of those users who will still see a need to edit Websource scripts myself.
This is not so much because the contents of superfluous tag fields bother me - my workflow for new albums already provides for an action "Remove fields except" which solves this problem.
Many scripts provide much more information than is in my interest. For example, since I'm not interested in the specific tag content of MusicBrainz and Apple, these fields in the UI in the "Adjust tag information" window bother me because they distract from content that interests me and often also require horizontal and vertical scrolling to find the information for to keep an eye on essential tag fields.
Therefore, my routine of calling the editor with each new web source script version and appending a series of "Set Tagfeld" lines at the end of the script will unfortunately have to remain the same.
I would therefore be interested in settings that could also influence the appearance of the "Adjust tag information" window in the way I described it.
That will be in the settings for my BP scripts. A checkbox to remove X tag.
I just need to find the time to update them.
Just to better understand it:
Why is a checkbox to remove X tag better/faster/easier then uncheck it directly in the "Adjust tag information"?
The last selection of tags (checked / unchecked) will be remembered, so you have to choose your preferred tags only once per script in "Adjust tag information".
Because people still edit the scripts and mess them up somehow. It's just and option not to have them clutter the UI with unwanted tags by the user.
But checking/unchecking in the UI of the "Adjust tag information"-window has only influence on the tag-fields that are saved in the file. I edit the script so that I don't even see unwanted fields in the UI because they take up unnecessary space, which in turn requires horizontal and vertical scrolling depending on the script. In addition, additional fields that do not interest you at all prevent you from having an immediate view of the essentials.
People editing the scripts are fine by me, but it is a problem when they share them and don’t follow up when they fail or contain bugs. It is a frustration when others come to me telling why it doesn’t work, and it is because they or someone else made changes that was the reason for the fails.
Another suggestion would be to add an option to be able to add settings into IndexUrl or other options, like $var(var_name) or similar?
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.