Inconsistent language use ("Remove" vs. "Delete") in Downloads Home |
||||||||
Issue descriptionThe M55/M56 Clank Downloads Home UI uses the term "Remove" as a tooltip on the trash icon. The Android Downloads app uses "Delete" as a tooltip on the same icon. The Clank Bookmark Manager UI uses "Delete" on the same icon. See screenshots In addition, Chrome Zine has been using "Remove" for non-destructive removals of suggestions since M54. AFAICT, in English (thanks vitaliii), "Remove" has a stronger connotation of "removing something from a collection without necessarily erasing it", while "Delete" has a strong connotation of "erase". The current inconsistency, creates issues since Downloads suggestions in Zine can be "Removed" (which doesn't cause the download to be deleted), while the "Remove" option in Downloads home actually deletes the file. I suggest Downloads Home to move to "Delete" to be consistent with Zine, the Chrome Bookmark Manager and Android Downloads.
,
Nov 17 2016
Source for "Remove" vs "Delete" difference http://english.stackexchange.com/questions/52508/difference-between-delete-and-remove
,
Nov 17 2016
Delete seems like the right call in the downloads home. Can we make this change?
,
Nov 21 2016
What is a progress on this? I would like to see this in M56. On the NTP we show a context menu "Remove" in the downloads section to remove a suggestion, but leave the underlying file. This is a problem if in Downloads UI "Remove" deletes a file.
,
Dec 6 2016
Yes, we should make this change. Dan, can you update? If so, can we merge for M56?
,
Dec 8 2016
,
Dec 9 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/adcd6b19c1830e2750bf0e0ca4de4c542ffbacbe commit adcd6b19c1830e2750bf0e0ca4de4c542ffbacbe Author: dfalcantara <dfalcantara@chromium.org> Date: Fri Dec 09 23:23:20 2016 [Download Home] Remove -> Delete Change message to show that clicking on a trash can actually deletes items instead of just removes them, even though the operation is "remove" by the DownloadHistory backend. BUG= 666292 Review-Url: https://codereview.chromium.org/2564053003 Cr-Commit-Position: refs/heads/master@{#437685} [modify] https://crrev.com/adcd6b19c1830e2750bf0e0ca4de4c542ffbacbe/chrome/android/java/res/menu/download_manager_menu.xml
,
Dec 10 2016
,
Dec 10 2016
Your change meets the bar and is auto-approved for M56 (branch: 2924)
,
Dec 10 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/eb5e22be192ab7167bb0cfcb232715fefff70018 commit eb5e22be192ab7167bb0cfcb232715fefff70018 Author: dfalcantara@chromium.org <dfalcantara@chromium.org> Date: Sat Dec 10 00:55:24 2016 [Download Home] Remove -> Delete Change message to show that clicking on a trash can actually deletes items instead of just removes them, even though the operation is "remove" by the DownloadHistory backend. BUG= 666292 TBR=twellington@chromium.org Original-Review-Url: https://codereview.chromium.org/2564053003 Original-Cr-Commit-Position: refs/heads/master@{#437685} Review-Url: https://codereview.chromium.org/2565083002 . Cr-Commit-Position: refs/branch-heads/2924@{#442} Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059} [modify] https://crrev.com/eb5e22be192ab7167bb0cfcb232715fefff70018/chrome/android/java/res/menu/download_manager_menu.xml
,
Dec 10 2016
,
Dec 13 2016
,
Jan 4 2017
Verified in M56-56.0.2924.51 |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by nepper@chromium.org
, Nov 17 2016157 KB
157 KB View Download
121 KB
121 KB View Download
650 KB
650 KB View Download