Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

On a related note, I live in Germany and like setting my device's language to en-US. I like the US news, as they are personalized to my taste anyway.

What I dislike is that temperature and distance in a couple of apps are now in US units, which I find unreasonable. I should be able to choose SI units if I want to.

Windows has been getting locale settings right for ages now. I find it sad that Android is so far behind in that regard.



I have my Android device set to use en-GB as its primary language for metric units, my spell checker is set to en-US, and my Google News is set to India.

What you want is already possible. However, I do wish the platform allowed a more direct customization of all LC_* stuff.

> Windows has been getting locale settings right for ages now.

Do you mean Windows phone? If so, I'm impressed. If you meant Windows, the computer OS series, well, that would not be a fair comparison for Android. Linux already gets that right.


When I switched from Android to Windows Phone back in 2012, I was surprised with the quality of the localization. I lived in a very small town in the middle of Brazil and even so, the dictionary knew all regional words, town names and prety much anything I tried to type on it.

Everytime I use iOS or Android, I'm quickly reminded that that is not the case outside windows phone.


> What I dislike is that temperature and distance in a couple of apps are now in US units, which I find unreasonable. I should be able to choose SI units if I want to.

And I'm in the opposite situation: I prefer British English but want traditional units only.

This really should be user-settable. Heck, even outside of America some folks prefer decimetres over centimetres!


even outside of America some folks prefer decimetres over centimetres!

? Isn't a decimetre a metric measurement?


Yes, and I'm guessing gp was suggesting that I might want my units in dm rather than cm.


even outside of America some folks prefer decimetres over centimetres!

But the US uses feet and inches.


Yes, and in regions outside of America there are folks who prefer to see lengths in decimetres and there are folks who prefer to see lengths in centimetres. Sure, it's easy to convert by sliding a decimal point, but they want to see the order of magnitude they're used to.


Windows has been getting locale settings right for ages now.

That's because those settings were designed before the era of "simplify everything that could even slightly potentially confuse an idiot user" and have been retained from then. I wouldn't be so sure if the future Windows versions will still be as customisable, given that they've already removed things like the ability to change fonts and colours in the UI. It's almost a given that sooner or later someone will come across it, think "let's overhaul/refresh/'enhance the UX'", and turn it into a totally sleek and stylish but less functional version of what it used to be.


Meh. iOS gets all of this trivial localization stuff right (correct timezones including UTC, en-CA spelling dictionaries, not conflating locale and location, etc), even though Apple is often accused of being the poster child for oversimplification


Apple manages to do it just fine. Although the advanced settings are a little threadbare on iOS they are very powerful on OSX and still serviceable on iOS.


OS X, just for example, hasn't allowed users to cut and paste files for years and years, for fear that the poor darlings might be confused when cut files, unlike cut text, remain in place until pasted. This isn't just a default setting; they removed file-cutting from the OS.

I love my MacBook, but Apple makes stupid decisions just like anyone else.


> This isn't just a default setting; they removed file-cutting from the OS.

They didn't remove anything. No version of Mac OS ever applied the cut-paste metaphor to the filesystem, going all the way back to 1984.

It's a Windows concept.


Cmd-C and Cmd-Opt-V copy and move a file for me just fine in El Cap.


Right, but the Finder does have Copy and Paste. Cmd-C and Cmd-V have worked in the Finder since the very first Mac. It's even in the edit menu.

I suppose they expect you to click and drag to move a file, rather than the slightly unintuitive Cut and Paste on entire files. There's no real physical analogy for a cut.


cmd-opt-v...


All right. Refusing to implement a useful feature for anyone because it's deemed too confusing for novices isn't any better than removing a useful feature because etc., though.

(The recent addition of a special hotkey to paste-with-delete is not much of an improvement, since it still obfuscates the actual, expected behavior (of Ctrl-X) in favor of a different, more obscure, but notionally "friendlier" alternative.)


Amen to that. I find it clumsy to require two finder windows open to move a file between them. Why not cut a file from one directory, open another directory, and paste it there? Ugh!


Most people don't seem to know this, but you basically can cut and paste in the Finder.

First copy the files you want, then move them instead of pasting (Command-Option-V). This gives you the same behavior without the confusion/danger of the files being lost in limbo between cutting and pasting, which I think is honestly better UX design.


In windows if you don't paste the files somewhere they just go back to their original location like they were never "cut" in the first place. Cutting without pasting is not a dangerous or destructive operation.


I think the OP means in all other apps, cutting means removing the selection and put it in the clipboard until it is pasted somewhere. Windows Explorer override this behavior by turning cut into move, which break the semantic and may create confusion that the file might go away if user didn't choose to paste it, if user have used cut in other program but not Explorer.


This is subjective. How would you cut/paste a 200 gigabyte file anyway?


The way this works on Windows (I think) is that internally, "cut" means "copy file path to clipboard", and "paste" means "move file from old place to new place". Thus, if you want to cut and paste from "Downloads" to "Documents", then it doesn't matter how big the file is: you just change a couple of directory entries without ever changing the file. If you want to do this across file systems, it has to do a copy.


I regularly use cut/paste to move files in Windows and Linux, not sure why the size is relevant.

Ctrl-a to select all files for example, ctrl-x to cut, alt-tab or navigate to a different directory and ctrl-v to paste.


> not sure why the size is relevant

Because typically cutting deletes, not marks. This seems like a great implementation though.


You don't have to load it in memory. The desired behavior can be accomplished with mv.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: