Language dependent default property value in settings

try put properties.xml with only this one default values in each language directory (like string)

Hm, that probably would work, but it makes translations a bit harder. Would be better if it was possible to use @Strings.defaultValue as a reference.

Well, it doesn't work.

I have 3 resources folder: resources (the default, with the English "translation"), resources-heb (Hebrew), resources-hun (Hungarian).
When I finally managed to try the settings on the watch/Garmin Express this is the strange behaviour I found:

1. When I open the App Settings editor in Garmin Express, it displays the settings in Hungarian instead of English.... I'm not sure why this happens, but I guess it's related to this bug: https://forums.garmin.com/developer/connect-iq/i/bug-reports/bug-simulator-s-app-settings-editor-doesn-t-have-default-language

2. However worse than that, because the prefixes are displayed in Hebrew!

Here is the file structure:

resources/properties/properties.xml - removed the strings, left only the boolean properties.
resources/properties/translatable-properties.xml - the 4 default English string properties were moved to this file.

<property id="intHrPrefix" type="string">w </property>

    <setting propertyKey="@Properties.intHrPrefix" title="@Strings.settingsIntHrPrefixTitle">
      <settingConfig type="alphaNumeric" maxLength="3"/>
    </setting>

I've made some test and it probably doesn't work for languages because properties are overwritten by device resource.

But what is the target CIQ for your app? If it is from 2.4 you can

- check if property is null

-than read def prefix from string in correct language

-and use Properties.setValue()

@_psx_ I came up with that idea (did not implement) as well. But I would like to display that default in the settings, which is not on the watch but on the phone / GE (because this is a data field)

It won't help in the short term, but maybe we should ask Garmin to enable to use @Strings in the properties. Maybe something like:

<settings propertyKey="@Property.foo" title="@Strings.fooTitle">
    <settingConfig type="alphaNumeric" default="@Strings.foo" maxLength="3" />
</settings>

I haven't tested it but i think properties are synchronised in two direction, so when user installes app it first run it and you put def value from strings. To change properties on phone you have to have BT on, so there will be synchronisation of settings. if there is 2v way synchronisation It's almost 100% it will run.

but of course it would be more elegant to use @string in def properties.xml. But i doubt it will be in this century :-)

btw, I'm wonder what do you want exactly to translate?

you can use string list and it is translated auto you can add 'other'  and read it from  text input

I suspect this is more complex than you think.  Let's say the user configures an Arabic character, yet the watch is set for English.  The font on the watch won't be able to display it.  The same kind of thing comes up when a watch is set for French and the user gets a text/email in Chinese, for example

You are right in this, but I'd leave that to the user. For my use case mixing languages would even be valid. The prefix/postfix is to display 2 things in 1 field: external (ANT) and internal HR. So the default would display something like:
i: 72 | e: 70
but in some languages (I don't know which) it might be that it will need some postfixes, something like:
72 I | 70 E

And it's even valid that we mix languages, and thus the user will type in the prefix, I can't provide it in a drop-down, because for example my son's watch is connected to my phone. The phone is in English, but he likes the watch to be in Hebrew, so in this case I'll edit the prefixes to be:
ש 72 | ר 70

If it's not displayed on the watch then the user will change it.

Other use case: when I run and the External HR sensor is on my partner and I want to see the partner's HR, so I can even use our names/initials:
G 72 | N 70

I can confirm this isn't supported at this time. You can do language-specific string overrides (e.g. for settings labels), but not for property values. That said, you have a valid use case, and I'll submit it as an improvement. It's something that's been discussed before and certainly seems like a reasonable thing to expect.