Under Review
over 1 year ago

BUG : String resource with a double quote character renders as escaped

If a string resource includes a double quote character (ASCII code 34), then the string is rendered incorrectly with a backslash escape character. For example, consider this string resource for a lat/lon position format that will be used as an option in a setting.

<strings>
    <string id="IncorrectString">hddd°mm'ss"</string>
</strings>

When that resource is retrieved and displayed, the result is displayed with an extraneous backslash character as such:

hddd°mm'ss.s\"

This happens regardless of how I try to escape or replace the quote character. CIQ is able to handle other replacements (eg. &apos; or &#176;) so it seems to only be an issue with the double quote character. For reference, I've tried:

  • hddd°mm'ss.s"
  • hddd°mm'ss.s\"
  • hddd°;mm'ss.s&quot;
  • hddd°mm'ss.s&#34;
  • hddd°;mm'ss.s&#x22;
  • hddd°;mm&apos;ss.s&quot;

All of those tries above return the same string with the backlash character: hddd°mm'ss.s\"

This happens in both the simulator and on various actual/physical devices.

I don't know if this is a holdover/bug related to this *old* issue -- https://forums.garmin.com/developer/connect-iq/f/discussion/126/cannot-escape-quotation-marks-in-strings/596 -- but I don't see how to accomplish this. And I looked at the Strings example code in case there was a weird way/workaround but none of the strings in that sample code include a quote character.

This occurs with SDK 4.1.6 but I don't know how long it's been like this.

dbrobert
Parents
  • over 2 years ago

    As you look to be dealing with a lat or lon, why have the string as a resource?  I can't see why it would need to be localized as it's the same in any language.  Build the string yourself.

    Or just use the API function  toGeoString() with GEO_DMS and let the system generate the string that can be easily split into lat and lon..

Comment
  • over 2 years ago

    As you look to be dealing with a lat or lon, why have the string as a resource?  I can't see why it would need to be localized as it's the same in any language.  Build the string yourself.

    Or just use the API function  toGeoString() with GEO_DMS and let the system generate the string that can be easily split into lat and lon..

Children
  • over 2 years ago in reply to jim_m_58

    I don't see how it's remotely trivial, except in a US/English centric world. A big part of the resources, aside from only loading the strings you need, is to support other languages. If I want to display something in quotes (for whatever reason), it's "Hello World!" in English but in French you will usually see the use of guillemet, as such: « Bienvenue! ». So simply adding a double quote doesn't work because now I suddenly have to check the language, etc.

    I don't think this is necessarily a seven year old bug; the one that is linked above is to do with string variables not string resources. They are potentially two different things. Which is why I reported the bug in the first place.

  • over 2 years ago in reply to dbrobert

    Still a trivial work around (add your own double quote in the app) for something that's been like this for 7 years.  Which SDK are you using, as it may be fixed (I doubt it) in the latest.

  • over 2 years ago in reply to jim_m_58

      I am NOT looking for a solution to generate a lat/lon, I am reporting a bug with string resources. The quote character is valid within an XML in the manner I have presented.

    Regardless, that was simply the example I used, since it was the first thing to come to mind where a quote character might be needed within a string resource. But to counter your point, it would be localized because if it is used as a list entry in a setting or as part of a layout then the compiler warns you if you use hard-coded strings. It would also be localized for any language that wasn't Latin based; "hour, minute, second" is "시 분 초" in Korean.