In my opinion, using a localization system with the English (or any other language) translation as the key of the translations file is wrong. I'm all for string keys with generic names that make life easier and (among other things) don't bloat the files with unnecessary text . Like in Android and, as far as I know, unlike in iOS, which also uses translations as keys.
Looking at the code of the Localizer class, the format of the locale files could be changed to something like <ComponentID>.<PropertyName>, i.e.:
Code:
//en.js
{key: "buttonBrowse.text", value: "Browse..."},
{key: "buttonBrowse.tooltip", value: "Browse for a file."},
//es.js
{key: "buttonBrowse.text", value: "Explorar..."},
{key: "buttonBrowse.tooltip", value: "Elige un archivo."},
So you could continue iterating through the localizable properties but instead of checking for the English string you would do it exactly for the element and property that you want. You could even implement a fallback method where in the case that you couldn't find a translation in a certain locale (replace==null) you could still use the English text as a last resort. This might require to load the English strings no matter what the current locale were or implement some kind of on-the-fly string loading, although I don't think this would be necessary.