Localizable.strings is parsed only if it is added to the project in a folder reference

[imrekel]

If the Localizable.strings file is directly referred by the project, it is not parsed by rgen.

I have tracked the bug to the point that ResourcesGenerator receives loadFileReference:targetName: with the XcodeFile name:"Localizable.strings" and absolute path:"/Users/Test/Dev/Test/Localizable.strings", but then comes this check to see if it is a directory:

if ([[NSFileManager defaultManager] fileExistsAtPath:absPath
                                       isDirectory:&isDir] && isDir) {

Since this is not a directory but a file, the check fails and the code which would detect that it is indeed the Localizable.strings file, never executes. I don't really see why would I have to add strings resources via folder references.

I have tried that if I add an arbitrary folder reference, containing the Localizable.strings file then it is recognized correctly, e.g.:

This issue affects monolingual files only (which doesn't have multiple variants).

[wader]

Not really sure myself why i only looked for strings in folder references. Haven't really used the localization parts that much.

The strings-fileref branch now will parse all .strings file references as localization string files. Is that good or should it only look for Localization.strings? Actually this is the same fix i sent to someone via email some month ago that used rgen for a OS X project :)

[imrekel]

It works. Since custom .strings files aren't supported by rgen right now, it should by fine like this. Thanks! 👍

[wader]

How do you mean custom .string files?

Im wondering if it should look for .strings extension instead of Localizable.strings for folder references and variable groups too.

[imrekel]

I mean that if you have an arbitrary strings file in your project, e.g. Foo.strings, you still need to refer to the filename to load the string, can't just use the S.bar to load the string with NSLocalizedString, e.g. using NSLocalizedStringFromTable(S.bar, @"Foo", nil).

So "not supporting custom strings files" may not be the case (since you can use the above mentioned method), but it is not that convenient this way. I wonder if it would be a good idea to add properties to the class of S for each custom strings file (e.g. foo for Foo.strings) and via those you could somehow get the keys and the filename references together.

A method of the generated class referred to by the foo property:

NSString* barStringWithComment:(NSString *)comment;

Which you could use somehow like this:

NSString* barFromFooLocalizedString = [S.foo barStringWithComment:@"comment if needed..."];

Some other methods may also need to be generated to support other string accessor functions like NSLocalizedStringFromTableInBundle.

Anyhow, this is just something that has come to me right now and maybe this is not a great idea for some reason.

[wader]

Ah now I understand. Yes that seem like a nice approach to me, so go ahead and implement it if you feel like it.
Is there a risk that the change in the stings-refs branch will add strings to S that won't work when it currently only uses NSLocalizedString? (sorry haven't had time testing that)

Maybe we should split this issue into two, one for .strings file references and one for your idea for adding fancy support for custom string files?