20190529 1350

[devinreams]

Latest based on mozilla-lockwise/lockwise-ios#992

Looks like it really wants to translate those bundle names (CredentialProvider, Firefox Lockwise).

But this should expose the Face ID usage description as noted at mozilla-lockwise/lockwise-ios#1009

[Pike]

Would the paths continue to roundtrip with the Strings/en.lproj in them?

[Pike]

The Strings/en.lproj path insert is surprising to me.

[devinreams]

Would the paths continue to roundtrip with the Strings/en.lproj in them?

@Pike Yes I believe so. I think the original inclusion of the InfoPlist.strings was at an incorrect path in the project so after doing some cleanup and removing of redundant files (and I just tried it again) this is what the result is.

I looked at the Localizable.strings and its included in Xcode and configure the same way. So I'm not sure why this would change now but don't see any way to "put it back" on this side.

[Pike]

Looping in Matjaz. @mathjazz, can you take a look at this, and see if the changed file path drops many localizations in Pontoon? Might just be a single Lockwise string at this point?

[flodolo]

Looping in Matjaz. @mathjazz, can you take a look at this, and see if the changed file path drops many localizations in Pontoon? Might just be a single Lockwise string at this point?

The update script already dropped them: it reads the strings, and inject them in the template. If the file path changed, that translation doesn't exist in the translated XLIFF.

If you look at German, you'll see that the translation for Lockwise has been removed.

P.S. Reminder that Matjaz is on PTO for the next week ;-)

[Pike]

OK, dug a little deeper, and this is actually a regression in @joeyg's export branch.

https://github.com/joeyg/ios-l10n-scripts/blob/fb87542e86e6ead31e44012fd929db833dfc99c3/export-locales.sh#L98 doesn't catch the new /Strings/ path.

I'd be OK with just the few string being lost and keeping the /Strings/ in the filepath, but I think we need a fix to at least remove the en.lproj in the path.

[joeyg]

@Pike ahh great catch. Sorry about that

[devinreams]

I think we need a fix to at least remove the en.lproj in the path.

OK, since this blocks additional strings being exported (we may have 1 for a future release, fairly uncommon) I will submit a change to @joeyg's fork/branch and re-submit an extract here.

[devinreams]

Revised output at #6