Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#10992 - Translating <untagged> in Database Viewer

Attached to Project: Rockbox
Opened by Rui Araújo (Akur) - Tuesday, 09 February 2010, 23:56 GMT+2
Last edited by Jonathan Gordon (jdgordon) - Thursday, 20 May 2010, 15:25 GMT+2
Task Type Patches
Category Language
Status Closed
Assigned To No-one
Player Type All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
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 .
   untagged_translated.patch (1.7 KiB) 
 apps/tagtree.c           |    6 ++++++
 apps/lang/english.lang   |   14 ++++++++++++++
 apps/lang/portugues.lang |   14 ++++++++++++++
 3 files changed, 34 insertions(+)

This task depends upon

Closed by  Jonathan Gordon (jdgordon)
Thursday, 20 May 2010, 15:25 GMT+2
Reason for closing:  Accepted
Additional comments about closing:  thanks! in r26192.
Comment by Rui Araújo (Akur) - Wednesday, 10 February 2010, 02:19 GMT+2
Just to correct a very tiny mistake in portugues.lang. A missing '>'... ;)
   untagged_translated.patch (1.6 KiB) 
 apps/tagtree.c           |    6 ++++++
 apps/lang/english.lang   |   14 ++++++++++++++
 apps/lang/portugues.lang |   14 ++++++++++++++
 3 files changed, 34 insertions(+)

Comment by Jonathan Gordon (jdgordon) - Wednesday, 10 February 2010, 05:31 GMT+2
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, 12:17 GMT+2
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.
   untagged_translatedv2.patch (2.5 KiB) 
 apps/tagtree.c           |    6 ++++++
 apps/lang/english.lang   |   14 ++++++++++++++
 apps/lang/portugues.lang |   14 ++++++++++++++
 apps/tagcache.c          |    2 --
 apps/tagcache.h          |    3 +++
 5 files changed, 37 insertions(+), 2 deletions(-)

Comment by Jonathan Gordon (jdgordon) - Wednesday, 10 February 2010, 18:27 GMT+2
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) - Thursday, 11 February 2010, 00:41 GMT+2
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) - Thursday, 11 February 2010, 00:45 GMT+2
ok cool :)
Comment by Jonathan Gordon (jdgordon) - Thursday, 11 February 2010, 00:46 GMT+2
oh, umm... does this change the sort order at all?
Comment by Rui Araújo (Akur) - Thursday, 11 February 2010, 00:54 GMT+2
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...
   untagged_translatedv3.patch (2.6 KiB) 
 apps/tagtree.c           |    7 +++++++
 apps/lang/english.lang   |   14 ++++++++++++++
 apps/lang/portugues.lang |   14 ++++++++++++++
 apps/tagcache.c          |    2 --
 apps/tagcache.h          |    3 +++
 5 files changed, 38 insertions(+), 2 deletions(-)

Comment by Rui Araújo (Akur) - Thursday, 11 February 2010, 01:29 GMT+2
No.. I tested it..
Comment by Thomas Martitz (kugel.) - Tuesday, 20 April 2010, 18:45 GMT+2
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...