Exporting Android Text with non positional arguments leads to lint warning

[Nailik]

Describe the bug Tolgee exports strings for Android in a way that they are reported by android lint. This is only visible when running the build command and not directly in Android Studio.

To Reproduce Steps to reproduce the behavior:

1. Define a text with 2 tolgee universal placeholders for example:{0} um {1}
2. Export for android
3. The export is: %s um %s
4. When building an Android project with this text there is a warning: Multiple substitutions specified in non-positional format of string resource string/at_with_placeholder. Did you mean to add the formatted="false" attribute?

Expected behavior Tolgee exports should not lead to a lint warning.

Possible solutions (i would prefer if you can choose which one to use while exporting, like a selection box where you can either choose: use non-positional arguments with formatted="false" or use positional arguments. Also allow to set it when exporting it via rest. If the decision is to not make this selectable then use positional arguments for android because hiding warnings is always worse than fix them in the first place.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.

[Nailik]

no it's not completed! @JanCizmar the bot should really stop just closing issues.

[JanCizmar]

Bad bot! 🤖

[Nailik]

@JanCizmar the issue with "named" arguments still exists {name} will be incorrectly exported as %s but {0} is correctly exported as %1$s.

[JanCizmar]

@Anty0 has this been ultimately fixed?

[Anty0]

@JanCizmar I think we discussed possible solutions, but if I remember correctly, no solution has been implemented yet. There is no good way of consistently assigning the same index to the same named argument within the bounds of the current implementation. One option discussed was to use the order of named arguments within the original (default) language to create a mapping of name->number and then use this mapping for all other languages. This would require another preprocessing step during export - going through all keys and generating this mapping table.

[Anty0]

Closing in favor of #3054.