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
Translation: 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$@
Translation: %1$[Assunto]@ %2$[contém]@ %3$@
Screenshot of the source string in Crowdin:
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.
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
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]@";
"%[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).
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.
