Closed Havhingstor closed 1 month ago
I wonder if it's sime to remove the pro key I provide in DeepLClient. It's a nice fallback when instance translate is not available, but it's expensive.
And I can also remove the default DeepL client.
And I can also remove the default DeepL client.
Still thinking about it, I need to review the case where the app use this instead of the instance service. I think it's when the instance service is missing and when the user doesn't have a free key. But there is a lot of usage.
I'm gonna change all the string keys to clear text later
Once it's done, all good I'll merge. Thanks!
Just a thought: In StatusRowViewModel, if the instance or DeepL translation fails (because we now removed the app's own PRO key), what if we fallback to Apple translate (without even showing an error) for users on iOS 17.4, where the feature is available?
Sounds good! I'd still keep DeepL as the first fallback for the instance if the user has a key, though
I think I've transformed all the keys I've added to clear text strings, and I've also removed your API key, and made DeepL and the Instance fallbacks for each other and Apple Translate for both.
Thanks!
🚀
Instead of just their instance and DeepL, the user has now the option between their instance, DeepL and Apple Translate. The user's previous choice (DeepL on / off) is reflected in the first value of the new setting and the old always_use_deepl App-Storage Key is deleted. The option is only available on iOS 17.4 or later and not on Mac or Vision Pro. If the user is on an unsupported platform but the option to use Apple Translate is set, it's reset to use the instance.
This also includes a couple of fixes that aren't necessary for Apple Translate, but related:
Tested on iPhone, iPad, Mac & visionOS Simulator