You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If .strings contains two keys that differ just by case, the order of entries in the generated .swift file is not stable from invocation to invocation.
This is quite edge case, given that (as far as I understand) SwiftGen does not support multiple entries that differ just by case, but it still happens in our case, as we have to entries that differ just by case of keys and number of parameters, like below.
Localizable.strings:
"A" = "Foo";
"a" = "Bar %s";
The other rationale for this change is that the current case-insensitive sorting does not make that much sense in case camelCase is used for the keys: capital letters in camelCase typically introduce a grouping/another "word", but lowercase letters just introduce word variation. From that perspective I believe that word variations should better belong to one group.
I honestly had to dig for quite a bit (because of the repo split -> back to one repo), until I found the change that added this: d774a7c
From the discussion in that PR, I can't seem to find any mention WHY we did it, nor are there any issues around that time related to this. It was probably done because it's "nicer" to have things alphabetically. Sorting case-insensitively is usually better/more readable 🤷
Note that at in that same PR eventually switched to $0.key.caseInsensitiveCompare($1.key) == .orderedAscending 9a70cd2
During the repo split, that got reverted to comparison using lowercased(), maybe because I thought the former is an NSString method... Does using caseInsensitiveCompare have stable sorting for your issue? If so, I'd prefer to use that, just so we can keep the nice(r) sorting 😄
djbe
changed the title
Output is not stable in the presence of the .strings keys that differ just by case.
Strings: unstable output for keys that differ just by case
Nov 26, 2021
djbe
linked a pull request
Jul 22, 2022
that will
close
this issue
If .strings contains two keys that differ just by case, the order of entries in the generated .swift file is not stable from invocation to invocation.
This is quite edge case, given that (as far as I understand) SwiftGen does not support multiple entries that differ just by case, but it still happens in our case, as we have to entries that differ just by case of keys and number of parameters, like below.
Localizable.strings:
The other rationale for this change is that the current case-insensitive sorting does not make that much sense in case camelCase is used for the keys: capital letters in camelCase typically introduce a grouping/another "word", but lowercase letters just introduce word variation. From that perspective I believe that word variations should better belong to one group.
Demo of the issue: https://github.com/grigorye/SwiftGen-Case-Insensitive
The text was updated successfully, but these errors were encountered: