Rockbox

  • Status Closed
  • Percent Complete
    100%
  • 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 .

   untagged_translated.patch (1.7 KiB)
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 '>'… ;)

   untagged_translated.patch (1.6 KiB)
jdgordon commented on 2010-02-10 04:31

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.

   untagged_translatedv2.patch (2.5 KiB)
jdgordon commented on 2010-02-10 17:27

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.. ;)

jdgordon commented on 2010-02-10 23:45

ok cool :)

jdgordon commented on 2010-02-10 23:46

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…

   untagged_translatedv3.patch (2.6 KiB)
Akur commented on 2010-02-11 00:29

No.. I tested it..

kugel. commented on 2010-04-20 16:45

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...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing