Rockbox

Tasklist

FS#10992 - Translating <untagged> in Database Viewer

Attached to Project: Rockbox
Opened by Rui Araújo (Akur) - Tuesday, 09 February 2010, 22:56 GMT
Last edited by Jonathan Gordon (jdgordon) - Thursday, 20 May 2010, 13:25 GMT
Task Type Patches
Category Language
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

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 .
This task depends upon

Closed by  Jonathan Gordon (jdgordon)
Thursday, 20 May 2010, 13:25 GMT
Reason for closing:  Accepted
Additional comments about closing:  thanks! in r26192.
Comment by Rui Araújo (Akur) - Wednesday, 10 February 2010, 01:19 GMT
Just to correct a very tiny mistake in portugues.lang. A missing '>'... ;)
Comment by Jonathan Gordon (jdgordon) - Wednesday, 10 February 2010, 04:31 GMT
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.
Comment by Rui Araújo (Akur) - Wednesday, 10 February 2010, 11:17 GMT
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.
Comment by Jonathan Gordon (jdgordon) - Wednesday, 10 February 2010, 17:27 GMT
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?
Comment by Rui Araújo (Akur) - Wednesday, 10 February 2010, 23:41 GMT
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.. ;)
Comment by Jonathan Gordon (jdgordon) - Wednesday, 10 February 2010, 23:45 GMT
ok cool :)
Comment by Jonathan Gordon (jdgordon) - Wednesday, 10 February 2010, 23:46 GMT
oh, umm... does this change the sort order at all?
Comment by Rui Araújo (Akur) - Wednesday, 10 February 2010, 23:54 GMT
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...
Comment by Rui Araújo (Akur) - Thursday, 11 February 2010, 00:29 GMT
No.. I tested it..
Comment by Thomas Martitz (kugel.) - Tuesday, 20 April 2010, 16:45 GMT
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

Loading...