• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category User Interface → Language
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Akur - 2010-02-09
Last edited by jdgordon - 2010-05-20

FS#10992 - Translating <untagged> in Database Viewer

This is a patch so that the string <untagged> can be translated.

It does that simply by checking for tag matches "<untagged>" and if it does substituting the tag with a translation.

The patch already includes the addition for the english and portuguese version.
This was reported on  FS#10976 .

Closed by  jdgordon
2010-05-20 13:25
Reason for closing:  Accepted
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

thanks! in r26192.

Akur commented on 2010-02-10 01:19

Just to correct a very tiny mistake in portugues.lang. A missing '>'… ;)

a few issues.
1) use straight strcmp() because the <Untagged> string is hardcoded so it wont ever be any other case, and you want to compare the full string, comparing against MAX_PATH is just wrong!
2) move the "<Untagged>" #define into a .h if you want to use it in more than 1 .c
3) I'm not entirely sure where tcs.result comes from, but what you are doing is almost certainly overwriting something, double check that you arnt please.

Akur commented on 2010-02-10 11:17

ok. I have changed it according your comments.

About the tcs, as I understood from the code, it is a struct which contains the data from a tagcache search. As I just want to change the name "<untagged>", every time it finds a new tag to process, I checked if it is a positive match and if it is, I overwrite the name and the name length according to the translation.

As this struct will be rewritten at the beginning of the loop, I think there isn't a problem with me overwriting it.

if the translated string is shorter than the onbuilt one, yes that will be fine, but if it is longer wont it overwrite some other info?

Akur commented on 2010-02-10 23:41

No because this tcs struct is the result of only one tag. And the tcs.result contents come from a statically allocated buffer with size of MAX_PATH*2+32, so it is not overwriting anything.

Besides while trying to understand the code I made logf's of every single variable to be sure I wasn't screwing anything.. ;)

ok cool :)

oh, umm… does this change the sort order at all?

Akur commented on 2010-02-10 23:54

I also meant that as long the translated string is not so big that it can't fit that buffer, there isn't a problem.

But here's a new patch with just a new check for this situation. If the translated string is too big it won't translate.
Furthermore if this ever happens I would say that the translation should be reviewed…

Akur commented on 2010-02-11 00:29

No.. I tested it..

I'd rather use strlcpy instead of that if so that at least a part of the string is displayed (which will in turn make the translator fix the translation). It als returns the size of the source string so that that result_len would be MIN(strlcpy_result, MAX_TAGLEN).

/me wonders what result_len is needed for


Available keyboard shortcuts


Task Details

Task Editing