Variables misidentified in NSPredicateEditor localisable strings

Crowdin misidentifies some variables in localisable strings that were created for Apple’s NSPredicateEditor or NSRuleEditor classes. The format of these these strings appears to be a special case for these two classes. I could not find any documentation by Apple, but this blog post explains the syntax.

For example:
Article matches %1$[any]@ of the following conditions

Artigo corresponde a %1$[quaisquer]@ das seguintes condições

Crowdin identifies both %1 and [any] as variables and tells translators not to translate these. However, the text within brackets (here: [any]) should be translated. The $ and @ characters are not treated as being part of the variable, even though they are. If the QA option “Variables mismatch” is enabled, Crowdin will display an error dialog when [any] is changed to [quaisquer].

Another example:
%1$[Subject]@ %2$[contains]@ %3$@

%1$[Assunto]@ %2$[contém]@ %3$@

Screenshot of the source string in Crowdin:
Screenshot 2023-01-13 at 17.00.31

In this example, Crowdin identifies 5 variables and discourages translation of [Subject] and [contains]. It should recognise %1$[]@ and %2$[]@ as single variables and allow translation of text within the brackets.

Hello, @Eitot an interesting post, thanks. Can you share a few sample files with me so I can run tests from my side?

If it’s fresh new tool, and there’s no official Apple documentation I suppose it’s expected that platform recognizes it differently as they really are.

Try searching for supported formats, maybe it’s similar to something that’s already supported

Here are two short test files (I can’t put more than 2 URLs in my post)


Base.lproj/Predicates.strings (English base localisation)

"%[All]@ of the following are true" = "Article matches %1$[all]@ of the following conditions";
"%[Subject]@ %[contains]@ %@" = "%1$[Subject]@ %2$[contains]@ %3$@";
"%[HasEnclosure]@ is %[Yes]@" = "%1$[Has enclosure]@ %2$[Yes]@";

de.lproj/Predicates.strings (German localisation):

"%[All]@ of the following are true" = "Artikel erfüllt %1$[alle]@ der folgenden Bedingungen";
"%[Subject]@ %[contains]@ %@" = "%1$[Betreff]@ %2$[enthält]@ %3$@";
"%[HasEnclosure]@ is %[Yes]@" = "%1$[Hat Anhang]@ %2$[Ja]@";

The strings on the left side are the keys in the source (which cannot be changed) and the strings on the right side are the localised values. The source strings are weird like this, because they are automatically generated by NSPredicateEditor and derived from query language (similar to SQL, but not exactly).

You can also see an example here: Crowdin (the project is public, you should be able to access it).

When you hover over [contains] Crowdin recommends to not translate this word.

1 Like

Hy @Eitot thanks for the files and details, much appreciated. I’ll do some tests. Please note that it may take some time.

Hello @Eitot

Here is an update:

Words in [], the system highlights them automatically, it’s a default behavior.

Theoretically, we can develop a custom script in order to ignore this. What comes to mind, is the idea of adding \ to [ on the import, so the word in [] wouldn’t be a variable, and removing \ on the export, so your file remains unchanged.

But, it’s a theoretical assumption. Must say we haven’t received any similar requests in past. I’d suggest you submit this as a Feature request, in case it gets a lot of votes, we’ll review this possibility in a more detailed way and put it on the roadmap.