Skip to content
This repository has been archived by the owner on Feb 22, 2021. It is now read-only.

Updates to Finnish and Swedish translations. Strings improvements. #124

Merged
merged 10 commits into from Apr 20, 2014

Conversation

mhuhtala
Copy link
Contributor

  • Changed English strings to use 'Wi-Fi' consistently. Before, there was a mixture of 'wifi', 'Wifi' and 'Wi-Fi'. 'Wi-Fi' is the registered trademark and it's what Google seems to use at least in the Settings and Drive apps.
  • Changed the wording of the new image fetch mode setting to be a bit simpler and more in line with Google's design guidelines. "Load images automatically" used to be a setting in Mozilla/Firefox, so maybe some users are familiar with it (it's since been removed from the Firefox UI).
  • updated Finnish and Swedish strings

@FredJul
Copy link
Owner

FredJul commented Apr 18, 2014

Hi mhuhtala! Thanks for this.

I just have a concern about the "Load images automatically", "Never", "Only over Wi-Fi" and "Always" translations. My initial english translation may not be perfect, but I think your ones do not reflect the reality.

With "Only over Wi-Fi", FeedEx will still load the images when you enter into the entry, it just do not preload it. I think the "preload" word is really important. And concerning the "Never" word, this is not that it do not preload images, but even load and display them.

In fact I think I'll modify the code to have:

  • a "Never Dislay Images" checkbox
  • a "Image Preload Mode" with "Never", "Only over Wi-Fi" and "Always". Only activated when the checkbox is not checked

I think it is more logical. Are you OK with this? If yes, I'll included your modification and then add the new checkbox later.

@mhuhtala
Copy link
Contributor Author

Yes, I realized almost as soon as I pushed the changes to Github that I'd misunderstood the preload options. Sorry about that.

A separate checkbox for "never display" certainly makes things clearer, if you don't mind adding another option to the settings. That's fine by me.

I was trying to avoid the term 'mode'. Google's guideline seems to be for a more plain sentence, e.g. simply "Preload images - Never / Only over Wi-Fi / Always".

@mhuhtala
Copy link
Contributor Author

I'm going to implement the "never display" checkbox.

@FredJul
Copy link
Owner

FredJul commented Apr 19, 2014

It was implemented before, but I stupidly remove it. You can still find the checkbox code and translation into the git history.

@mhuhtala
Copy link
Contributor Author

Ok, thanks. I'll try to complete this in my branch, if that's okay?

@FredJul
Copy link
Owner

FredJul commented Apr 19, 2014

It is perfect ;) thank you very much!

@mhuhtala
Copy link
Contributor Author

I pushed a new version with the 'display images' checkbox on my branch.

The "display, but never preload" setting is a new configuration compared to the previous situation, but it's actually not handled explicitly anywhere in the code, it's the default behavior in the conditional statements. replaceImageURLs in HtmlUtils no longer checks for settings at all, because the method is only called if image display is on, in which case all images need to be downloaded at that point anyway.

@mhuhtala
Copy link
Contributor Author

On a second thought, I'm not sure that these image download options are the most sensible ones.

  • The "display, but never preload" is probably not a useful thing to have. If the user is willing to download all images at view time regardless of the type of network connection, they might as well be preloaded. I.e. "do not display" and "never preload" probably should be combined, the way they are in the current release version.
  • If the user absolutely does not want to download images while on a mobile data connection, the current "Wi-Fi only" option is not that useful, because FeedEx will start to download the images regardless of the type of connection at view time anyway.
  • Then again, if the user does want to see the images always, but would like to save on mobile data usage where possible, the current "Wi-Fi only" option makes sense.
  • The options could be
  1. Never download, never display
  2. Preload only over Wi-Fi, load only over Wi-Fi
  3. Preload only over Wi-Fi, load over any connection
  4. Always preload

These could be in a single AutoSummaryListPreference titled "Images in entries". Options 2 and 3 would need to be worded better in the menu.

FredJul added a commit that referenced this pull request Apr 20, 2014
Updates to Finnish and Swedish translations. Strings improvements.
@FredJul FredJul merged commit 455de32 into FredJul:master Apr 20, 2014
@FredJul
Copy link
Owner

FredJul commented Apr 20, 2014

Thanks for your work! However I stayed with the checkbox + preload options and did some little changes to the code.

This is how I see the different options:
1/ no images: do not use 3G/Wifi data for images
2/ never preload: will use 3G/wifi data only when you're reading an entry.
3/ wi-fi only: when fetching the feed list, if Wifi enabled we try to download the images. When reading the article, if the image has been preloaded we display it immediately otherwise we download it with 3G/Wifi data
4/ always: we have plenty of data and cache memory, always try preload images for better reading

I personally find disturbing the "load only over Wi-Fi" due to the fact that the user will sometimes have the images, sometimes not. And as you say "fetch mode" isn't very beautiful, and since you mixed display option and preload options (as I did previously) you cannot use the "preload images" title for that preferences.

Not sure I'm very clear...

@mhuhtala
Copy link
Contributor Author

Yes, I get it. It would be a little confusing to see some images but not others in a total "Wi-Fi only" mode. Personally, I don't really care, since I'm on a fixed price, no limits mobile data plan, and don't normally use Wi-Fi at all.

eighthave pushed a commit to eighthave/spaRSS that referenced this pull request Mar 20, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants