First of all: Thanks for developing and sharing Laurine, I really like it a lot!

Unfortunately with the recent release of Xcode 7.3 Laurine Generator produces the following error and warnings:

Version 7.3 beta (7D129n)

/usr/local/bin/LaurineGenerator.swift:47:2: error: unknown attribute 'exported'
@exported import Darwin

~: brew install jiritrecak/laurine/laurine
Warning: jiritrecak/laurine/laurine-0.2.0 already installed

Hi,

Regarding Git the script becomes a little annoying because of the timestamp added to the documentation header:

// // Autogenerated by Laurine - by Jiri Trecak ( http://jiritrecak.com, @jiritrecak ) // Do not change this file manually! // // 2015-12-14 at 5:48 PM //

That makes the file to be included on every commit just because of the date time update.

I think there are two options to deal with this:

1. Do not add it so if there are no updates to the file It will not record anything to git
2. The best one could be check the OUTPUT_PATH Localization.swift file modification date and compare it to SOURCE_PATH Localizable.strings e.g:

if Localizable.strings.modificationDate > Localization.swift.modificationDate { do rebuild } else { ignore since there is no changes }

What do you think?

Nested Structures don't seem to be working in the latest version on github for Swift. I tried both of these: "PROFILE-NAVIGATION_BAR-ITEMS-DONE" = "Done" // -c -d - "PROFILE.NAVIGATION_BAR.ITEMS.DONE" = "Done" // -c -d .

I tried specifying and leaving the defaults, neither worked. I even tried adding a new string to the example and that didn't work.

It changed it to /// Base translation: Thanks everyone! You rock! public static var ContributorsFooter : String = "Contributors.Footer".localized

Introduction & My approach

Hello guys, I am glad you are enjoying this project so much - it is trending, people write about it, and I really strive to make it the ultimate solution for translations in the application.

Now, the base is already great, but what is really missing is support for Plurals. You probably know how it is done in the iOS - instead of writing it to .strings, you generate .stringsdict (plist, really) that contains rules for how the word should change with different number of X.

I am not the biggest fan of that approach, but it is what it is and we have to work with what we have (plus there is probably not better solution, I know). I would like to know feedback about this topic. My idea is following:

• The parser will scan the folder where Localizations.strings reside and look for .stringdict.
• If it finds it, it will parse it and get all the keys from it
• For each key / value pair it will generate method the same way as you would use it from standard .strings file

The output would then look like this:

Localizations.Profile.Friends(1) // 1 Friend
Localizations.Profile.Friends(2) // 2 Friends
Localizations.Profile.Friends(10) // 10 Friends

What do you say? What are your opinions about this?

Possible enhancement for future version

Now as I mentioned, I am really not the biggest fan of .stringdict file - it is complicated to write. So I was thinking that it could be possible to write plural localizations directly from strings. Obviously, I would never want to build that decision engine, that is way out of scope of this project and would be completely pointless, but, imagine following. Instead of writing everything to .stringdict, write it to .strings as following:

"Localizations.Profile.Friends[one]" = "%d Friend";
"Localizations.Profile.Friends[few]" = "%d Friends";
"Localizations.Profile.Friends[many]" = "%d Friends";

key in [] is the same key that you would use in dictionary to write rule. Except you would not need the dictionary, because that would be built dynamically by the system and then fed to iOS localization engine (if that is possible, which I am, so far, unsure of.

Do you think we could change the base format of the localizations and do you think it is viable, or it seems like too much over-engineering and we should just stick with .stringdict?

Thank you for your feedback!

Warning: Calling Formula.sha1 is deprecated!
Use Formula.sha256 instead.
/usr/local/Library/Taps/jiritrecak/homebrew-laurine/laurine.rb:4:in `<class:Laurine>'
Please report this to the jiritrecak/laurine tap!

Warning: Calling SoftwareSpec#sha1 is deprecated!
Use SoftwareSpec#sha256 instead.
/usr/local/Library/Taps/jiritrecak/homebrew-laurine/laurine.rb:4:in `<class:Laurine>'
Please report this to the jiritrecak/laurine tap!

Warning: Calling Resource#sha1 is deprecated!
Use Resource#sha256 instead.
/usr/local/Library/Taps/jiritrecak/homebrew-laurine/laurine.rb:4:in `<class:Laurine>'
Please report this to the jiritrecak/laurine tap!

Sorry for the last pull request, I messed it up and created a new one :D But good thing: I created it to the develop branch ;) Added method to only use alphanumeric properties (filters out every value and replaces spaces with _) if non conventional localization keys were used :) Added also some safety checks that should add more crash prevention.

Hi,

Actually the code does not support frameworks properly, the generated String extension:

private extension String {

    var localized: String {
        return NSLocalizedString(self, tableName: nil, bundle: NSBundle.mainBundle(), value: "", comment: "")
    }
    func localizedWithComment(comment:String) -> String {
        return NSLocalizedString(self, tableName: nil, bundle: NSBundle.mainBundle(), value: "", comment: comment)
    }
}

It's using _NSBundle.mainBundle()_, as a result if you call a localized var from the App target, the system will load the localized string from the localization file of that target and not from the framework.

I'm testing a little hack:

private extension String {

    var localized: String {
        return NSLocalizedString(self, tableName: nil, bundle: NSBundle(forClass: LocalizationsBundleClass.self), value: "", comment: "")
    }
    func localizedWithComment(comment:String) -> String {
        return NSLocalizedString(self, tableName: nil, bundle: NSBundle(forClass: LocalizationsBundleClass.self), value: "", comment: comment)
    }
}
internal class LocalizationsBundleClass {}

I created an internal dummy class in order to fetch the correct bundle via:

NSBundle(forClass: LocalizationsBundleClass.self)

The name of this dummy class should be based on the values in the script e.g: OUTPUT_PATH="$BASE_PATH/Path_To_Output/_Localizations_.swift"

Although I'm not sure if this is the more optimal solution.

If I understand the usage correctly, you need to remove instances of NSLocalizedString and its variations from your code, and then replace them with the corresponding generated Localizations.… properties and variables.

But then, this means that genstrings command won't be able to extract these strings again, as it won't find them. How is then further maintenance of Localizable.strings supposed to happen?

What happens if a string is no longer used in the code? it will live forever in Localizable.strings and Localizations.swift unless manually removed, is that correct?

Is there any way to get this to work with the Xcode "Export for localization" functionality? When I create a custom Localizable.strings file to use for Laurine (which rocks by the way), the content of that file does not get exported to my xliff files.

Hi, First of all I must to say this Lib is Just AWESOME!..

One thing is that in my project I'm using a framework to share functionality between extensions and the App, said that I want to keep every single localization string within the framework so it can be used by all the extensions and the App itself.

But at the moment it's not working because the generated code are not public.

I get this error when running in Xcode 10.2 - Swift 4.2

0. Program arguments: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift -frontend -interpret /Users/emil/Virksomheder/Projekter/sense-ios/Sense/Sense/Libraries/LaurineGenerator.swift -enable-objc-interop -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -module-name LaurineGenerator -- -i /Users/emil/Virksomheder/Projekter/sense-ios/Sense/Sense/Assets/en.lproj/Localizable.strings -o /Users/emil/Virksomheder/Projekter/sense-ios/Sense/Sense/Helpers/Localizations.swift -c true 0 swift 0x00000001080cfee3 PrintStackTraceSignalHandler(void*) + 51 1 swift 0x00000001080cf6bc SignalHandler(int) + 348 2 libsystem_platform.dylib 0x00007fff71114b5d _sigtramp + 29 3 libsystem_platform.dylib 000000000000000000 _sigtramp + 2398008512 4 libswiftCore.dylib 0x00007fff70959c09 _swift_updateClassMetadataImpl(swift::TargetClassMetadata<swift::InProcess>*, swift::ClassLayoutFlags, unsigned long, swift::TypeLayout const* const*, unsigned long*, bool) + 265 5 libswiftCore.dylib 0x00007fff70959c4b swift_updateClassMetadata2 + 27 6 libswiftCore.dylib 0x000000010b1d14ce swift_updateClassMetadata2 + 2592569502 7 libswiftCore.dylib 0x00007fff70961b77 swift::MetadataCacheEntryBase<(anonymous namespace)::SingletonMetadataCacheEntry, int>::doInitialization(swift::ConcurrencyControl&, swift::MetadataCompletionQueueEntry*, swift::MetadataRequest) + 215 8 libswiftCore.dylib 0x00007fff709573f3 swift_getSingletonMetadata + 579 9 libswiftCore.dylib 0x000000010b1b01af swift_getSingletonMetadata + 2592444415 10 libswiftCore.dylib 0x000000010b1b013c swift_getSingletonMetadata + 2592444300 11 swift 0x000000010496719d llvm::MCJIT::runFunction(llvm::Function*, llvm::ArrayRef<llvm::GenericValue>) + 365 12 swift 0x000000010496d572 llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&, char const* const*) + 1090 13 swift 0x0000000103f365d1 performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*, swift::UnifiedStatsReporter*) + 58913 14 swift 0x0000000103f246de swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 6862 15 swift 0x0000000103ec27be main + 1246 16 libdyld.dylib 0x00007fff70f2f3d5 start + 1 /Users/emil/Library/Developer/Xcode/DerivedData/Sense-amrxbuahpzprwaepprxlnxrnivph/Build/Intermediates.noindex/Sense.build/Debug-iphoneos/Sense.build/Script-FD357AEE20B807A500F1DB2E.sh: line 27: 6297 Segmentation fault: 11 "$LAURINE_PATH" -i "$SOURCE_PATH" -o "$OUTPUT_PATH" -c true Command PhaseScriptExecution failed with a nonzero exit code

Currently when Laurine generates the static vars, there is no comment:

public struct Localizations {
    public struct Project {
        public struct Example {
            /// Base translation: An example project
            public static var Title : String = NSLocalizedString("Project.Example.Title", comment: "")
        }
    }
}

In my case, I use a BartyCrouch script after the Laurine script, which uses the comments to populate all my other translation files (everything is in 24 languages in my app).

They end up with a useless comment on every key:

/* No comment provided by engineer. */
"Project.Regional.Title" = "";

I'd really like to have the option to tell Laurine to use the Base translation as the comment, so to get a better result:

• Laurine

public struct Localizations {
    public struct Project {
        public struct Example {
            /// Base translation: An example project
            public static var Title : String = NSLocalizedString("Project.Example.Title", comment: "An example project")
        }
    }
}

• BartyCrouch

/* An example project */
"Project.Regional.Title" = "";

Hi,

I added a podspec so that I could use Laurine in my project using cocoapods.

It's easier for projects already using cocoapods because there is nothing else to install, just add it to the Pod file and do the usual and it's available for the build script. Also the path to use in the build script is the same for everyone.

I'm using it currently in my project, and I'm happy I can use it this way, because my collaborators won't have any configuration/install to do. Same for the CI, nothing more to configure (although I did not test that yet).

The PR is there if you want it.

Add a few missing keywords (fileprivate, open, etc.) that have been introduced in recent Swift versions, and removed some that are no longer available (__FUNCTION__, __FILE__, etc.).

Used the list of keywords here for reference: https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html

Hi!

Laurine, for some reason, just doesn't see this localization string: "Error.Title.General". It doesn't even create a top-most struct for the Error. Is it intentional behaviour?

Thanks in advance.