Repeated usage about laurine HOT 3 CLOSED

Hello Victor,

Yes, you are absolutely correct with your understanding. Thought, I'd like to add two things that come from my experience (and you might have different one, but here is my piece):

Having keys / values in code is terrible when building huge projects. It is not on one place and therefore, maintenance is hell. Also, it goes against usual paradigms of other languages (see android, where you cannot even write a string into the code, you have to define it through XML).

Second thing is that by having plain keys on different places in the application, usually those will end up being in different formats (like "Profile.NavigationBar.X" and somewhere else you will find "Main Menu - Something").

This is especially hard to control when you have more people building one application. Also, it present problems with source control as the changes happen on many places at ones, you are changing basically whole files.

Personally, I think that genstrings tool has no place in Swift because swift allows you to strongly type almost everything and Laurine (or for Storyboards - Natalie) is the prime example of this.

I find this workflow the best:

• Create key / value in en.proj/.strings
• Add NSLocalizedString to code (or with Laurine, cmd+B and then add code)
• Once enough changes have been made or you want to translate to different language, upload to CrowdIn, and import remaining translations

Hope this gives you some insight how, and why :)

Have a nice day!

Jiri

from laurine.

As for removing NSLocalizedString with actual code, converter tool is coming probably within the month, that will do that for you (but it is quite complicated, so no promises on date yet.)

from laurine.

Thanks Jiri,

yes I'm aware of the maintenance nightmare of using string literals within the code, that's why I have all of them as constants/enums in a centralized file. But I could not use that approach for localization, as genstrings is confused when not using actual strings.

I'm thinking I can always write code using NSLocalizedString until it is working and tested, and then run genstrings with the -a modifier to append to the existing file, and then replace the calls to NSLocalizedString with the Laurine-generated properties.

from laurine.