Acknowledged
5 months ago

Problem with installing app

One of my user has tried to install widget PSX-7 (https://apps.garmin.com/apps/1944b8b4-409e-482d-b7b3-becd4e8b1b05) but he couldn't due the incapability error but he has installed PSX-6 (https://apps.garmin.com/apps/e4ce9423-c37e-4aa7-b778-f24c2347c923). Both are built the same SDK (7.3.1m PSX-7 few days later), both have the same min API level to 2.4.

_psx_
  • 6 months ago

    Here's regexp you can use to find any language array (aka part number) which doesn't support English:

    I tested this in VS Code.

    Here's a similar regex to find all language arrays:



    Regexes in text form available here:

    https://pastebin.com/4v4RJ7qC

  • 6 months ago

    > I won't waste time to check jsons and language, simple I will check all languages, make default resources and because compiler uses tree to build resources it will use default strings for any language I will dicide to not translate...

    I don't think you have to do that. Just do what you do today -- select the languages that have non-default resources -- and also add English to the list.

    I did a quick check and out of 298 part numbers, only one of them doesn't support English: gpsmap67 (APAC)

  • 6 months ago

    > Supporting region or not shouldn't be done during compilation time but during putting application into store. 

    But as we all know very well, including/excluding devices by region happens at compilation time for another reason besides languages: minApiLevel in the manifest.xml.

    If minApiLevel is set to version X, then all part numbers with connectIQVersion lower than X will be excluded. Since APAC part numbers usually have connectIQVersion less than or equal to WW part numbers, then it's possible that if you set minApiLevel to a certain version, you will exclude APAC part numbers, but include WW part numbers (and it's not necessarily obvious that this happened until users start to complain.)

    As we all know, this has been posted about many times in the forums.

    I guess the problem (from Garmin's POV) is you're not just supporting regions, but you're supporting "part numbers" which are associated with regions. And Garmin only wants to export the part numbers which will actually be supported (they're fine with making that decision at compile time).

    Ofc the store page has separate regional limits.

    So in fact, Garmin has regional support in both cases (compile time and in the store config/submission page). Whether we like it or not, this isn't going to change.

    > But exclusion device without warning is not acceptable. 

    I agree 100%. I would have expected to see a warning for the language-based part number exclusion that looks like the warning for minApiLevel-based exclusion. e.g. If I set minApiLevel to 3.4.0 and build for instinct2s:

    "WARNING: Device name: 'Instinct® 2S / Solar / Dual Power' Part number: '006-B4091-00' CIQ ver: '3.2.7' is being ignored by the package tool because it does not support the minimum API Level set for this project"

    Maybe this can be a feature request.

  • 6 months ago

    Supporting region or not shouldn't be done during compilation time but during putting application into store. 

    Why there are language in manifest? Or why not checking languages is good and for who?

    - shorter compiling time 

    - saving space (especially in store and watch)

    - ...

    But exclusion device without warning is not acceptable. 

    I won't waste time to check jsons and language, simple I will check all languages, make default resources and because compiler uses tree to build resources it will use default strings for any language I will dicide to not translate...

  • 6 months ago

    There is no default language but there is default resource and inside "strings" - it means default strings.

    The manifest defines languages or nothing -> compiler builds languages or none but ALWAYS default.

    Watch, user -> language = LAN, starting app, system check if there is a resources for LAN, if not, simple load res from default.

    So if a dev prepare only default resource and inside Esperanto strings all will be shown in Esperanto independent of LAN.

    I understand all of that but again that doesn't explain how the compiler would know that your app supports English unless you say so, or you leave the languages unspecified.

    Your implicit answer would be that it doesn't matter (due to all the things you said above), but now we both know better.

    Why shouldn't the compiler include/exclude devices based on language support? It is this process that mandates that you list all the languages your app supports, if you choose to list any at all (otherwise the compiler just assumes you support English).

    > There is no default language but there is default resource and inside "strings" - it means default strings.

    Right and I already covered that. That covers the process of string lookups, but not the specification of what languages your app supports. Perhaps the mistake here was to assume that string lookup is the only way that languages have any effect on CIQ apps.

    > The complete lack of documentation around part numbers with respect to CIQ is a little disappointing.

    But actually, the behavior here is documented. If either of us had read the related docs recently, we would've seen the problem immediately.

    https://developer.garmin.com/connect-iq/core-topics/manifest-and-permissions/

    Languages

    Connect IQ apps can be localized across over 30 languages, and the languages your app support can impact what regions of the world your app is available in. In the manifest you can declare the languages your app supports, which will be used when exporting your application to the store. See Resources for more information.

    Notice how it does *not* say anything like: "the languages your app supports are only used to look up strings in resources, and nothing else".