Suppressing "used with multiple comments" warnings produced by internal "extract-loc-strings" command

[whitemarten]

Some translations are used multiple times throughout the code. In order to point out that the same translation might be used in different contexts, the comment for NSLocalizedString is different. This used to work fine with BartyCrouch 3, but in 4.0.0 Xcode is now flooded with these warnings:

/extractLocStrings:-1: Key "yyy" used with multiple comments "yyy" & "zzz"

Is there a way to suppress the warnings in the update/code" task for the "extract-loc-strings" command used internally?

Thanks in advance!

[Jeehut]

I could add back support for the deprecated genstrings command if extract-loc-strings is the issue, but before doing that, I'd like to know how the comment is supposed to look like when you have different comments at different places? And how is a translator supposed to profit from two different comments? To me it sounds like you should have two separate keys if you need different comments since the translator might decide to use a different word if the context is different. Further explanation on the benefits of your decision would help me make the right feature choice here.

[whitemarten]

Thanks for your reply. Sometimes a certain expression appears in multiple views. It has the same meaning and requires the same translation (e.g. "Current Location"), but we used to add a slightly different comment in order to give the translator a hint in which places to find the string in the app if he wants to look it up.

/* title for locations monitor alert
title for locations monitor table cell */
"Current Location" = "Current Location";

I don't think it's necessary to keep supporting deprecated genstrings. I was just wondering if there was a way to suppress extractLocStrings's warnings.

[magneticrob]

I'm in exactly the same position as @whitemarten - my project with 0 warnings now has loads because I have used multiple comments for certain strings. Having multiple comments for a localised string is a valid use case and the translators love it, I don't think we really need a warning for it

[Jeehut]

I just ran xcrun extractLocStrings without any path arguments to get this help output:

Usage: extractLocStrings [OPTION] file1.[mc] ... filen.[mc]

Options
 -f argumentsPlist        reads additional arguments from 'argumentsPlist'.
 -j                       sets the input language to Java.
 -a                       append output to the old strings files.
 -s substring             substitute 'substring' for NSLocalizedString,
                          multiple substitutions are comma-delimited.
 -skipTable tablename     skip over the file for 'tablename'.
 -noPositionalParameters  turns off positional parameter support.
 -u                       allow unicode characters.
 -macRoman                read files as MacRoman not UTF-8.
 -d                       attempt to detect encoding if read fails.
 -q                       turns off multiple key/value pairs warning.
 -bigEndian               output generated with big endian byte order.
 -littleEndian            output generated with little endian byte order.
 -o dir                   place output files in 'dir'.

Please see the genstrings(1) man page for full documentation

It doesn't seem like there's an option to turn off "used with multiple comments" warnings, but maybe the -q option will turn that off, too? I just tried this by creating a Test.swift file with these contents:

class Test {
    init {
        NSLocalizedString("key", comment: "Comment 1")
        NSLocalizedString("key", comment: "Comment 2")
    }
}

Then I ran this command:

xcrun extractLocStrings Test.swift

Which showed this warning as expected:

extractLocStrings: warning: Key "key" used with multiple comments "Comment 1" & "Comment 2"

But when I run this:

xcrun extractLocStrings Test.swift -q

Then there's no warnings!

So, there we have the solution, we just need to specify the -q command when running extractLocString. Is one of you guys up to posting a PR with the fix? I think we can turn on the -q option by default as BartyCrouch was never meant to show any warnings in such cases. If anyone relies on having these warnings then this could be added as an option to the lint command and documented in the README – but as it's not documented right now, no one should be expecting it.

Please also don't forget to update the CHANGELOG and credit yourself like here when posting the PR. Since there's an issue, the sentence should be something like Fixes #XX via #YY by Name.

[magneticrob]

Hey @Dschee , awesome response. Thank you.

I've created a PR here: 171, if there are any problems please let me know.

[Jeehut]

@magneticrob, thank you for the PR. I reviewed it, looks good overall, just a few minor changes.

[whitemarten]

Wow, that was quick. Thanks to both of you!

[Jeehut]

This was fixed in #171.