Translation for column headers in "List of search results"

In the List of search results the column headers are not translatet to the selected language. All other elements in the process of using a web source script from the tag sources menu to search for metadata are (at least partially) translated, including name of web source script, the search by input field names and column headers in adjust tag information.
Only at the step selecting a match from the list of search results the table containing the matches always has column headers that are written in english as defined in the WSS and that don't are translated to the selected language.
For me it seems that it should be possible to translate these headers, like it is done for the other parts in the search dialog.

That's mostly due to the fact [IndexFormat] is defined by the source author in one line:

[IndexFormat]=%_url%|%_coverurl%|%Title%|%Release Date%|%Overview%|%_preview%

I wouldn't say it's a bug but something that could be requested as a feature.

Possibilities
  • allowing multiple versions of [IndexFormat] along with a parameter like en,de,fr etc. to pair with the user's own language settings, meaning the source has to pre-load in ALL translations and the author has to maintain them all.
  • another file similar to how .settings stores and displays translations for each .src/.inc, or if done with enough flexibility could be called upon with something like [Include] for any .src/.inc's to pull column data from. Likely it'd be several lines for each file or one line where unneeded columns are simply skipped:
Source 1
[IndexFormat]=%_url%|%_coverurl%|%Title%||%Overview%|%_preview%
Source 2
[IndexFormat]=%_url%|%_coverurl%|%Title%|%Release Date%||%_preview%
  • same as above but separate files for each language, meaning users can save only the ones they need so Mp3tag doesn't have to pre-load many unused ones. It'd also mean other users could contribute their translations or maintain personally far easier without fear of destroying their copy of a file.

In the meantime, you could use emojis to help give a universal context to each column:
[IndexFormat]=%_url%|%_coverurl%|%:label:Title%|% :spiral_calendar:Release Date%|% :memo:Overview%|%_preview%

The documentation says:
[IndexFormat] Format string for splitting the output buffer from the first search pass into different fields.

I understand that the placeholders starting with %_ have a special purpose and need no translation. But I think that the others like %Artist%, that simply define the colomn headers, should be translated into the language the user has choosen. This is IMHO a bug, because it breaks the consistency of the user interface.

What I don't understand is, why [IndexFormat] is a format string with placeholder syntax, surrounding the column headers with %? Nothing of the functionality of format strings seem to be neither useful nor applicable here. If I omit the percent signs I always receive an error messages saying there are no matches to my search query.

That I agree with, having the % confuses it with actual %placeholders% where |%Artist%| is really just |Artist|.

This has the exact same as Columns where users have to input a heading into the Name field so I don't think it's a bug, unfortunately.

There's the potential if a heading is recognised as an equivalent to a %artist%/ARTIST tag that translation could occur. The problem then would be that custom headings that aren't official tags can't be translated unless more functionality is created for any user-inputted field that could mis-translate or not be desired in some cases.

Thanks for your feedback. I think that this is better treated as a feature request and I moved the topic to General Discussion

This is an implementation detail that not necessarily need to concern you. I'm using the index format as a matching format string (with the help of Mp3tag's internal functionality around format strings, similar to what's available at Filename - Tag). There are countless other ways of implementing this, but this is what I've chosen back in the time.