Localization: Add support for plist-based `.strings` files

[hmelder]

[hmelder]

@rfm this is also supported in recent MacOS versions

[hmelder]

If it parsed but produced the wrong information, log an error because the file is wrong. If it parsed and produced the right information, use it.

How can I verify this using +propertyListFromData:mutabilityOption:format:errorDescription:? Since errorDescription is just a string, it doesn't provide details about the error. This means I can't reliably determine the type of error that occurred. The only option in case of an error is to continue execution, which can be unpredictable. For instance, if parsing fails due to a syntax error in the plist, the method might continue and log confusing or misleading warnings.

[rfm]

I'm not sure the order in which you get error information is much of a problem, but while looking at this I realised that there already existed a private function for getting strings table content (and NSBundle wasn't using it for some reason), so I tweaked that to call +propertyListFromData:mutabilityOption:format:errorDescription: after failing with the standard strings file parsing and simplified (removed quite a bit of code) NSBundle by using it. I also added a tiny testcase for it. Does it meet your needs?

[hmelder]

But id GSPropertyListFromStringsFormat(NSData *data) GS_ATTRIB_PRIVATE; does not really solve the problem:

Since errorDescription is just a string, it doesn't provide details about the error. This means I can't reliably determine the type of error that occurred. The only option in case of an error is to continue execution, which can be unpredictable

Something like +propertyListFromData:mutabilityOption:format:error: and then continue if the blob was not recognized as a property list.

[hmelder]

@rfm

[rfm]

it doesn't provide details about the error. This means I can't reliably determine the type of error that occurred.

It seems to me that, at this point (we have determined that the file exists and have loaded it in) there is only one possible error: the content of the file cannot be parsed as a property list (ie it's not valid format in some way).

Certainly there's no obvious correct set of additional error information we can/should provide.

[rfm]

Closing this since the functionality all seems to be there. We can't really know in detail why parsing failed, but if we just want to know what the best guess is for the format of the file, we can call +propertyListWithData:options:format:error: to get that.