# Translation for column headers in "List of search results"
**URL:** https://community.mp3tag.de/t/translation-for-column-headers-in-list-of-search-results/71337
**Category:** General Discussion
**Created:** [May 24, 2026, 9:06am UTC](https://community.mp3tag.de/t/translation-for-column-headers-in-list-of-search-results/71337 "2026-05-24T09:06:00Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@yorickausyps](https://community.mp3tag.de/u/yorickausyps)
#### Post date: [May 24, 2026, 9:06am UTC](https://community.mp3tag.de/t/translation-for-column-headers-in-list-of-search-results/71337/1 "2026-05-24T09:06:00Z")
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.
---
### Author:  [@arb](https://community.mp3tag.de/u/arb)
#### Post date: [May 24, 2026, 3:01pm UTC](https://community.mp3tag.de/t/translation-for-column-headers-in-list-of-search-results/71337/2 "2026-05-24T15:01:15Z")
That's mostly due to the fact `[IndexFormat]` is defined by the source author in one line:
```auto
[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:
>
> ```auto
> Source 1
> [IndexFormat]=%_url%|%_coverurl%|%Title%||%Overview%|%_preview%
>
> ```
>
> ```auto
> 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%|%`🏷`Title%|%` 🗓`Release Date%|%` 📝`Overview%|%_preview%`
---
### Author:  [@yorickausyps](https://community.mp3tag.de/u/yorickausyps)
#### Post date: [May 25, 2026, 9:15am UTC](https://community.mp3tag.de/t/translation-for-column-headers-in-list-of-search-results/71337/3 "2026-05-25T09:15:52Z")
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.
---
### Author:  [@arb](https://community.mp3tag.de/u/arb)
#### Post date: [May 25, 2026, 4:06pm UTC](https://community.mp3tag.de/t/translation-for-column-headers-in-list-of-search-results/71337/4 "2026-05-25T16:06:15Z")
> [@yorickausyps](#):
>
> why **`[IndexFormat]`** is a _format string_ with placeholder syntax, surrounding the column headers with %
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.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [May 26, 2026, 4:40am UTC](https://community.mp3tag.de/t/translation-for-column-headers-in-list-of-search-results/71337/5 "2026-05-26T04:40:37Z")
Thanks for your feedback. I think that this is better treated as a feature request and I moved the topic to #General Discussion
> [@yorickausyps](#):
>
> 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.
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.