extractLocStrings: error: bad entry in file /xxx/xxx: Argument is not a literal string.

[yikuo123]

if the tableName or key is a variable, this problem would occur. Could anyone tell me how can i ignore this error message?

[yikuo123]

BTW, BartyCrouch 3 is OK

[Jeehut]

There's no way we could support variables as keys or table names in a reasonable amount of time since this requires your app to be built and run and only during runtime would the actual values be really clear – and even then, they could change depending on your variable type. So basically, in order to use BartyCrouch, you need to use String literals. There's no way we could fix this, sorry.

[Jeehut]

Ah, I just saw that what you want to do is to simply ignore those entries, not infer them. Apple, over time, adds more and more error messages to their tools, in this case extractLocStrings – which is probably why BartyCrouch 3 was working fine (using the deprecated genstrings tool). I'm not sure if extractLocStrings has an option to ignore errors, if it has, we could use that.

We could also redirect those error messages to /dev/null which would fix the error. But then, you lose all the useful error messages, too. A fix could be to specifically ignore only this error. In any case, it could be fixed. But that's not implemented yet. Would be glad over a PR fixing this.

Having that said, if this only happens in a specific file in your project, the simplest workaround for you would be to make sure that file isn't processed by BartyCrouch by specifying a codePath where the file isn't included. Unfortunately, we don't have an exclude option yet, that would also be open to a PR.

[yikuo123]

@Dschee Can we just ignore this error message and then do nothing ? I wish BartyCrouch just didn't emit this error message.

[yikuo123]

@Dschee I get it, thank you for your answer

[andtie]

@yikuo123 You can trick extractLocStrings into accepting variables by wrapping it in a literal string.

E.g.: NSLocalizedString("\(localizationID)", comment: "\(comment) #bc-ignore!")

[thesunita]

This is what I am getting in my project.

Please Note DropDown and GoogleMapPlaces are thirdParty libraries used in project

[yikuo123]

@thesunita I think you may exclude the Pods directory

[thesunita]

I came across this https://github.com/Flinesoft/BartyCrouch/issues/63 before posting screenshot here.

I was assuming as PR has been merged , so /Pods should be there and should work. Do I need to do something else? May be a little help to get right path would be much appreciated.

Note: I have installed BartyCrouch on Mac OS using HomeBrew.

[Jeehut]

@thesunita Can you please post your .bartycrouch.toml file contents? This is most likely a configuration issue. BartyCrouch should actually ignore the Pods directory automatically, but depending on your configuration we might have to alter the logic since it seems, our logic isn't working in your setup ...

[ASamirbadran]

same issue here

[vince4]

I have the same issue using custom function :

static inline NSString *expLocalizeString(NSString *string, NSString *comment) {
    return [EXPCustomConstants localizedStringForKey:string table:@"Label" comment:comment];
}

Produce :

Starting Task 'Update Code' ...
2021-02-03 10:28:19.540: ✅  ../../:  Successfully updated strings file(s) of Code files.
Task 'Update Code' took 0.787 seconds.
extractLocStrings: error: bad entry in file /Users/vincent/Documents/App/exp-ios-core/Constants/EXPConstant.m (line = 326): Argument is not a literal string.
Command PhaseScriptExecution emitted errors but did not return a nonzero exit code to indicate failure

And the build fail.

The only workaround I found is to redirect the error to /dev/null : bartycrouch update >/dev/null 2>&1