Duplicate keys in different `.strings` files are incorrectly reported as missing/extra argument warnings

[jayrhynas]

My app has strings split across multiple .strings files, and some of those strings have the same key. Since all the strings were merged into one list in #19, duplicate keys aren't handled correctly since later occurrences of a key overwrite earlier ones when building the lookup dictionary. This can lead to various incorrect reports:

• warnings that the number of arguments don't match between languages (really, it's duplicate keys with different # of arguments)
• may cause missing localizations to be ignored, if they have at least one instance of the duplicate but not all

I may attempt to fix these issues, but I need to understand the rationale behind coalescing the .strings files in the first place.

[irskep]

Some apps do merge their strings files together, including Wikipedia, the app I mentioned in the PR. I'm not 100% sure what's allowed in terms of combining and splitting. I do think if we were to do the opposite—go back to 1:1 string file mapping—it would be less correct. At Asana we just use a single file, and I don't understand the use case of using multiple files.

(Steve here on a personal account)

[jayrhynas]

In our app we have our strings split across files for namespacing, then read them with Bundle.main.localizedString(forKey: key, value: nil, table: filename). This will read the string key from filename.strings. I feel like this is more the intended use case of .strings files, since without some custom build step combining the files, you can't look up strings without specifying the table name/filename.

[stevelandeyasana]

Fixed in #27. If you have time, I'd love it if you could install the version from that branch (steve/separate-strings-files) and let me know if it fixes your problem.

[stevelandeyasana]

This change has been released as part of 0.9.4.