Heyo :)

I love that you wrote this (and open-sourced!), since it solved a big pain point I've had before with localisation tools not being harsh enough in validation.

Would you consider adding a semi-stable (it's before 1.0, so... whatever goes) output format that could be parsed by other tools? My use-case is to have locheck be part of our CI suite, so we can make sure the strings we're merging are correct, but it's currently not super nice for that use-case. (I'm currently parsing the stdout output, and looking for lines that begin with "WARNING: or ERROR:, which, workable, but... yeah.)

JSON would probably be the easiest?

And I know that the README says:

Pull requests for additional output formats will probably be accepted.

but I wanted to check in with y'all if this is something you'd be even interested in / maybe are working on already, before I start hacking on it.

My app has strings split across multiple .strings files, and some of those strings have the same key. Since all the strings were merged into one list in #19, duplicate keys aren't handled correctly since later occurrences of a key overwrite earlier ones when building the lookup dictionary. This can lead to various incorrect reports:

• warnings that the number of arguments don't match between languages (really, it's duplicate keys with different # of arguments)
• may cause missing localizations to be ignored, if they have at least one instance of the duplicate but not all

I may attempt to fix these issues, but I need to understand the rationale behind coalescing the .strings files in the first place.

Hello, first off all let me say how awesome this tool is! I've run it on our iOS project and it works like a charm and since you have Android support, I also really wanted to try it out on our Android project!

When doing so, I hit the following issue:

$ locheck discovervalues ~/Code/GitHub/cookpad/global-android/ui-commons/src/main/res --ignore-missing
Error: Files encountered an error at '/Users/.../global-android/ui-commons/src/main/res/values-en-rGB/strings.xml'.
Reason: missing

I'm not too familiar with our Android project, but our base strings.xml is in the values directory, we then have some regional directories for values-en-rGB and so on but we don't localise strings for different regions (at least yet) so the values-en-rGB/strings.xml doesn't exist.

Now I figure this is something relatively easy to patch so I'm happy to try and submit a PR, but first i wanted to check with you on the expected behaviour. Is our project configuration common by not having strings.xml in every values directory? I guess I see at least three ways to fix this:

1. Ignore the values directory if it doesn't contain strings.xml
2. The above, but only when --ignore-missing is set?
3. A different option for passing locales/directories to ignore?

Let me know your thoughts! Thanks again 🚀

It would be nice if the tool could validate the base language without comparing it to translations to see if there are issues with things like position identifiers within stringsdict files. This would be great as an initial check that things are being properly formatted before being sent to translators, for instance.

Currently, locheck will ignore lines in .strings files that contain comments. It will also ignore lines if there is not exactly one space character before and after the = character in the line. These forms are however considered valid by Xcode and should not be ignored.

This PR extends stringPairRegex to match and ignore comments at the beginning and end of lines, and adjusts the regex to match *= * instead of =.

Currently, the regex still does not handle multi-line block comments that begin or end on the same line as a valid key-value pair. I'm undecided if we should just allow unbalanced */ or /* patterns at the beginning or end of a line, respectively, or if a broader multi-line parser would be more appropriate.

String arrays are a common practice in Android string xml files: https://developer.android.com/guide/topics/resources/string-resource#StringArray But they seem to not be recognized by locheck (above error)

1. Parsing and grammar

Parses strings like Hello %#@bob@ into lists of enums like [.constant("Hello "), .variable("bob")] stored on LexedStringsdictString objects. (Open to suggestions for the name.)

It then uses a basic recursive function to walk the grammar formed by the stringsdict entry's format key and rules to generate all possible permutations.

Example input:

transportation:
  format key: "%#@cars@ and %#@motorcycles@"
  cars:
    one: "one car"
    other: "%1$d cars"
  motorcycles:
    one: "one motorcycle with %#@sidecars@"
    other: "%2$d motorcycle with %#@sidecars@"
  sidecars:
    zero: "no sidecar"
    one: "one sidecar"
    other: "%3$d sidecars"

Example output:

[
 "one car and one motorcycle with no sidecar",
 "one car and one motorcycle with one sidecar",
 "one car and one motorcycle with %3$d sidecars",
 "one car and %2$d motorcycles with no sidecar",
 "one car and %2$d motorcycles with one sidecar",
 "one car and %2$d motorcycles with %3$d sidecars",
 "%1$d cars and one motorcycle with no sidecar",
 "%1$d cars and one motorcycle with one sidecar",
 "%1$d cars and one motorcycle with %3$d sidecars",
 "%1$d cars and %2$d motorcycles with no sidecar",
 "%1$d cars and %2$d motorcycles with one sidecar",
 "%1$d cars and %2$d motorcycles with %3$d sidecars",
]

2. Canonical argument list

Parses all permutations to find arguments, then makes sure each argument at each position has a specifier matching the other permutations.

--default doesn't exist and it's not mentioned in help. I think it was meant to be --base:

OVERVIEW: Automatically find .lproj files within a directory and compare them

USAGE: locheck discoverlproj [--base <base>] [<directories> ...] [--ignore <ignore> ...] [--ignore-missing] [--ignore-warnings] [--treat-warnings-as-errors]

ARGUMENTS:
  <directories>           One or more directories full of .lproj files, with one of them being authoritative (defined by --base). 

OPTIONS:
  --base <base>           The authoritative language. Defaults to 'en'.  (default: en)
  --ignore <ignore>       Ignore a rule completely. 
  --ignore-missing        Ignore 'missing string' errors. Shorthand for '--ignore key_missing_from_base --ignore key_missing_from_translation'. 
  --ignore-warnings       Ignore all warning-level issues. 
  --treat-warnings-as-errors
                          Return a non-zero exit code if any warnings, not just errors, were encountered. 
  -h, --help              Show help information.

Fix #26. Adds a --treat-warnings-as-errors flag to every command that causes warnings to result in a nonzero exit code even without errors.

I skipped unit tests because this code is very obvious. I did make test files by hand and verify the behavior.

Fix #7. Implicit position assignment acts as if explicitly-positioned arguments were not there. I determined this experimentally.

I would be very surprised if Android had different behavior, since this all seems to be based on C printf() behavior.

This PR officially makes Locheck a cross-platform project!

Adds support for an androidstrings command which can parse strings.xml and compare two translations to make sure all keys are present in both. Additional validation will follow in another PR but will be slightly simpler than Stringsdict validation.

I tested this by running it on Asana's English and German translations and found a bunch of missing keys that are really missing from German.

So if I have a Base localisation strings file with 2 entries in it, and a fr with 3 entries, and run locehck with --base Base, it doesn't see any problem. It seem like that this situation should be noticed as a warning?

As a work around, I am running locheck multiple times with every localisation file as --base, so it catches all possible orphans:

locheck ... -base Base
locheck ... -base fr

Locheck was hanging for me. I found out the problem was a line like this:

////////////////////////

I also found out that a line with a comment and no characters after the slashes has the same effect:

//

Thanks for this great tool, I have an improvement suggestion but not sure if it would be useful for everyone: a common case is when developers is waiting for translation is to put the English (base) text for other languages and forget about it.

Cheers !

Thanks for this great tool, I have an improvement suggestion but not sure if it would be useful for everyone: a common case is when developers is waiting for translation is to put the English (base) text for other languages and forget about it. I can open a PR with this added if you think it could be useful. Cheers !