[Feat] Honor the exact spelling of a translation key

[michaelosity]

Problem Statement

Code generation for the RemafoX.swift Loc enum may change the spelling of a translation key.

If you open the translation window and type in a translation key such as 'Button.Label.OK', the generated code to access the string is Loc.Button.Label.Ok.string. The generator changed the spelling of the translation key I typed fromOK to Ok.

My expectation is that a key I typed in would not be modified or transformed.

I try to adhere to the Apple spelling style so acronyms are upper case. It's HTML not Html, it's ID not Id, etc. So other keys like 'Item.ID' would be converted to Loc.Item.Id and provide other instances of this behavior.

Suggested Solution

I can imagine a few solutions to this problem.

(1) Give the option to never rename the text typed into the translation window. The spelling the user typed in is the spelling used to generate the code (assuming the spelling is a valid name for a property).

(2) Add an option of strings to never rename. For the example above, the option list might be OK, ID.

(3) Probably not the best idea, but there could be some adornment around the key to indicate that it is to be interpreted as-is. For example, a user would type in 'OK' (in quotes or some other hint) to indicate that the string is literal and should not be modified.

Additional Considerations

This is a purely additive change so it should not require anyone to use this option.

[Jeehut]

@michaelosity Thank you for requesting this feature. Options 1 and 2 make total sense to me, I'll see which one seems to fit better into the app once I work on this. Keep your feedback coming, I'll do my best to fulfill as many wishes as I can.

[Jeehut]

@michaelosity I just had a look into this topic and I've come to the following conclusion:

I think it will be best for all users if I adjust the default behavior of RemafoX to respect uppercase characters in keys to keep them as is to prevent the confusion you have run into. I considered the options you provided, but I'm reluctant to follow your suggestions mostly because they add another option for developers to know about and decide on. I want RemafoX to "just work" as much as possible. And I have a feeling that the use case you mentioned could be the only reason people might want to use this, so I want to default it.

I just worked on the next 1.5 release and wanted to include the change there, but I figured it would be a breaking change as some users might already have keys like Button.Label.OK in their codebase which currently is Button.Label.Ok in the code reference. If just changed the Ok to OK their projects would fail. The fix should be pretty obvious, but still, a breaking change is a breaking change and I want to do them on major releases only.

The good news is, the next major release 2.0 of RemafoX isn't that far away, I'm actually working on it already. I will include the above mentioned behavior change in that release to implement this feature request. I think users can be expected to do a little bit of migration when updating to a new major version (many users won't be affected anyways).

I hope that this consistency issue isn't too annoying and you can bear with me for a little longer. Thank you for your patience! 🙏 And thank you for reporting this in the first place. I'll help make RemafoX better for everyone.

[michaelosity]

Thank you for considering my request and your thoughtful reply. I think you made the right choice in fixing the issue and totally understand when that would be fixed. The app is fantastic! ///

…

On Apr 14, 2023, at 6:10 PM, Cihat Gündüz ***@***.***> wrote: @michaelosity <https://github.com/michaelosity> I just had a look into this topic and I've come to the following conclusion: I think it will be best for all users if I adjust the default behavior of RemafoX to respect uppercase characters in keys to keep them as is to prevent the confusion you have run into. In considered the options you provided, but I'm reluctant to do follow your suggestions mostly because they add another option for developers to know about and decide on. I want RemafoX to "just work" as much as possible. And I have a feeling that the use case you mentioned could be the only reason people might want to use this, so I want to default it. I just worked on the next 1.5 release and wanted to include the change there, but I figured it would be a breaking change as some users might already have keys like Button.Label.OK in their codebase which currently is Button.Label.Ok in the code reference. If just changed the Ok to OK their projects would fail. The fix should be pretty obvious, but still, a breaking change is a breaking change and I want to do them on major releases only. The good news is, the next major release 2.0 of RemafoX isn't that far away, I'm actually working on it already. I will include the above mentioned behavior change in that release to implement this feature request. I think users can be expected to do a little bit of migration when updating to a new major version (many users won't be affected anyways). I hope that this consistency issue isn't too annoying and you can bear with me for a little longer. Thank you for your patience! 🙏 And thank you for reporting this in the first place. I'll help make RemafoX better for everyone. — Reply to this email directly, view it on GitHub <#87 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATWZZ2I42PZYZIEBY3L3J3XBHYP7ANCNFSM6AAAAAAVVGTRIU>. You are receiving this because you were mentioned.