search

agilebits / onepassword-app-extension

1Password Extension for iOS Apps
2.58k stars 311 forks source link

Localization missing #347

Closed futuretap closed 7 years ago

futuretap commented 7 years ago

I see you're using NSLocalizedStringFromTable but I can't find any actual localization for these strings. Don't you provide any?

radazzouz commented 7 years ago

Thanks for taking the time to write to us, @futuretap!

The 1Password App Extension API is localizable, but it is not localized. In other words, we offer developers the ability to localize it in their project, the same way they would localize their app.

Our goal is to minimize its size and complexity of our API. Localizing it (bundling the translations) may lead to a lot of issues during the integration process.

Since this is not an issue, I am closing it as invalid.

Please let me know if this helps!

Cheers!

futuretap commented 7 years ago

I don't think it's time well spent if each and every developer needs to do the same localization again and again. I recognize the bundling issue but could you still provide localizations for the most common languages? That would be helpful. Other libraries and SDKs (e.g. HockeyApp) do the same.

radazzouz commented 7 years ago

Thanks for getting back to me,

Point taken! Thanks for clarifying this for me, @futuretap!

The easiest/recommended way to integrate with our App Extension API is to drag & drop the code and image assets (a total of three assets). Notice that it does not come (by default) as a .framework or .a, so developers would still have to manually move the translation strings from this repo to their own .lproj directories.

That said, at this time, we do not want to complicate the integration workflow for developers.

Also, please note that the 1Password Extension is localized and that the only localizable strings in this repo are logged errors (no UI strings) which should not be user-facing. They are directed at the developer integrating with our API.

Let me know if this helps!

futuretap commented 7 years ago

If the strings aren't user-facing, then why bother at all to localize them? We only noticed them because of our localization workflow that automatically scans the code for strings to be localized and adds them to the localizable strings. I guess many projects are configured this way. Of course, localization comes with a cost and thus I'd prefer if those strings wouldn't be marked for localization in the first place.