FIT Contributor UNITS

I think you're right. And if we're both right, then maybe the documentation of createField should remove the recommendation to translate :units to the current language, and instead keep it easy with a constant (i.e English) value, and thus prevent bugs like what I encountered here: https://forums.garmin.com/developer/connect-iq/i/bug-reports/feature-request-add-maxlength-maxsize-attributes-to-string-resources-and-fail-at-compilation-if-a-string-is-too-long  

1) Why are you responding to a post from 2020?

Especially when that post is somewhat misleading and missing context? (See below)

2) The OP is missing the larger point that *all* of the options for createField which are *also* specified in the fitContributions resource XML are ignored...by Connect, and to note that these are all strings.

i.e. It's not just :units, it's also the 1st arg to createField().

It might be helpful to...

2a) ...note that the strings in createField() still written to the FIT file

2b) ...consider that there is actually a good reason for Connect to use the fitContributions XML strings, rather than the createField() strings: the strings referenced in fitContributions XML can be properly localized, while the strings specified in createField cannot. Sure, you can follow the docs' recommendation to translate the strings in createField to the current language, but each of them can only ever be in one language. In contrast, the strings it fitContribution XML can be specified in multiple languages.

2c) ...consider that any 3rd party sites which display CIQ developer fields don't have access to fitContributions XML and would therefore have to look at the strings specified in createField() after all

I mean, I think you knew all of that, which makes it strange that you're acting like this is some baffling choice that was made for no reason.

As it stands, anyone who read the OP and your response might get several wrong impressions, like:

- it's only :units that's "ignored"

- there's no rhyme or reason for doing so

- that it's just a bug and not a deliberate design decision

- there's no reason at all to specify correct strings for :units (or any other string in createField which is also in fitContributions XML)

TL;DR

- it's not just :units, it's all the strings specified in createField() which are also in fitContributions XML

-- i.e. both the 1st arg to createField() (the field name) and the units are also in fitContributions XML, so by the OP's logic, they are both "ignored"

- it's not a bug; the actual reason is that fit contributor strings can be specified with multiple languages in the XML, while there's only one copy of the strings in createField

- 3rd-party sites would still need to reference :units (and other strings in fitContributions XML), so it's not like those fields are completely useless

flocsy🤠 said:

And if we're both right, then maybe the documentation of createField should remove the recommendation to translate :units to the current language, and instead keep it easy with a constant (i.e English) value, and thus prevent bugs like what I encountered here

This is really a strange comment, as you're cherry-picking one specific instance of translating a string that happens to be mentioned in the Connect IQ API docs, but your bug report refers to string resources in general. In short, even if they followed your advice and changed the doc, that's not really going to prevent the situation in your bug report in general, as devs will still use string resources (translated or not) for other reasons, since the feature will still exist.

Are you going to hunt down every thread about string resources in the forums and reply to it?

If you think that the doc should be changed, that's really a separate bug / request and very loosely (or not at all) related to the bug you linked.

Btw:

- the createField() example in the OP doesn't even use string resources (or otherwise translate the string) for createField() (either the first arg or :units)

- the createField() example(s) in the SDK samples don't use string resources for the first arg to createField or :units, or otherwise translate the strings

- I've never seen any 3rd party code which uses string resources for the first arg to createField or :units, or otherwise translate the strings

So you are complaining about advice in the docs which is ignored by everyone (including Garmin and the OP of this thread).

However, the fact that even Garmin ignores this advice might be a good reason for the docs to be changed (at least the note could be amended or clarified to explain that Connect doesn't use :units but 3rd-party sites might).

Maybe I should've linked the 2nd "bug" report: https://forums.garmin.com/developer/connect-iq/i/bug-reports/documentation-change-request-remove-or-elaborate-on-requirement-for-current-device-language-for-units-in-session-createfield

Come on! 2 TLDR comments that seem to show you misunderstood something in my comment, and then in your last sentence you get to the same conclusion?