View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009365 | Taler | wallet (Android App) | public | 2024-11-28 18:54 | 2024-12-13 18:15 |
| Reporter | Stefan | Assigned To | avalos | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | high | Severity | text | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 0.13 | ||||
| Target Version | 0.14 | Fixed in Version | 0.14 | ||
| Summary | 0009365: String adjustments in Android wallet [urgent] | ||||
| Description | 1. https://weblate.taler.net/translate/gnu-taler/wallet-android/en/?checksum=567988f81d9a524e&q=Receive&sort_by=-priority%2Cposition#translations shows the English string receive_peer_payment_instruction which was arranged on behalf of my email message of Sept 26 to the wallet devs. I wanted to have created a new key for peer-pull payments with the value "Let the payer scan this QR code to receive %1$s". Now, the string is in Weblate "Receiving %1$s, let the payer scan this QR code to send it" which could be improved. My suggestion is: "To receive %1$s, have the payer scan this QR code to send the amount." 2. Reciprocally, the same applies to the string send_peer_payment_instruction (see https://weblate.taler.net/translate/gnu-taler/wallet-android/en/?checksum=91d43a6e460ae4a3&q=Receive&sort_by=-priority%2Cposition) which is now "Sending %1$s, let the payee scan this QR code to receive it" and should better go as "To send %1$s, have the payee scan this QR code to receive the amount." 3. For the already printed English Taler merchant brochure, I most urgently need to have this English string changed: receive_peer (see https://weblate.taler.net/translate/gnu-taler/wallet-android/en/?checksum=0ef2f18dd337a916&q=Receive&sort_by=-priority%2Cposition) is now "Request money from another wallet" and should be "Invoice another wallet". 4. Also for the already printed Taler merchant brochure, I suggest to revert the string receive_peer_create_button (see https://weblate.taler.net/translate/gnu-taler/wallet-android/en/?q=receive_peer_create_button&sort_by=-priority%2Cposition&checksum=) which was changed a week ago from "Create invoice" to "Create request". Please make it "Create invoice" again, otherwise let me know the argument not to do so. Thank you for your work in advance. Cheers, Stefan | ||||
| Tags | No tags attached. | ||||
| Hi Stefan, I apologize for the late response. During the QC meetings we discussed plenty of changes in terminology, one of which was getting rid of the term “invoice” because it made it seem like the feature could be used for payments, when in reality it /should/ only be used for transferring money between friends or family. All of the strings that you pointed out are the result of such discussions, and now those strings are mostly consistent with iOS. | |
| I partially agree with 1 and 2, though. “Sending” makes it seem like the money is already in transit, but I would change “To send” to “In order to send,” and keep “let” instead of “have” because in my view it's simpler English. | |
| Hi Iván, I fully agree with the strings you propose and am happy that the term "invoice" got eliminated (points 3. and 4.). We are also clear about points 1. and 2. that we better avoid the gerund "Sending"/"Receiving" and have it replaced by your solution ("In order to send/receive, ...". I can imagine that Berna as an English mother-tongue speaker would probably give advice for finding a third way to express the same... but let's keep it with your proposition. In any case, we should not bother about string changes at all, without respect to any already printed brochures (as I wrote in a MM posting before). Cheers! S. | |
| Hello both, I have always had reservations about the term ‘invoice’ but chose not to voice them earlier, as I did not feel that my comments or comparisons were going over well with everyone. In my opinion, it is more accurately described as a ‘record’ of a transaction and should be labeled as such. Regarding ‘to send’ and ‘to receive,’ I suggest simplifying it further by removing ‘to.’ ‘Send’ and ‘Receive’ are clear, action-oriented terms, and the addition of ‘to’ is unnecessary.” My 2 cents. I looked at the strings, and Receiving %1$s, let the payer scan this QR code to send it -> I'd say: To receive %1$s, let the payer scan this QR code to complete the payment. Sending %1$s, let the payer scan this QR code to send it -> I'd say: To send %1$s, let the payee scan this QR code to accept/receive the payment | |
| Just for the protocol - the latest contributions from Mattermost's wallet channel (https://mattermost.taler.net/taler/channels/wallet): - send_peer_payment_instruction: "To send %1$s, show this QR code to the payee and have it scanned." - receive_peer_payment_instruction: "To receive %1$s, show this QR code to the payer and have it scanned." When at this moment during the process a smartphone gets rotated by 180 degrees or is tilted, the display should show another string "Scan this QR code to complete the transfer.", thus instructing the user's counterpart to scan the QR code (in the first case a payee, in the second case a payer). | |
| "Scan QR code to receive $AMOUNT." and "Scan QR code to pay $AMOUNT." This discussion ends here and now, too much waste. If you do UX studies, you can re-open it with real users. We cannot spend weeks discussing every tiny string. | |
| commit 6424797ae1119da37be9ca287c42714cb76d2f3d (HEAD -> master, origin/master, origin/HEAD) Author: Iván Ávalos <avalos@disroot.org> Date: Thu Dec 12 23:00:34 2024 +0100 [wallet] P2P QR code string adjustments bug 0009365 | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-11-28 18:54 | Stefan | New Issue | |
| 2024-11-28 18:54 | Stefan | Status | new => assigned |
| 2024-11-28 18:54 | Stefan | Assigned To | => sebasjm |
| 2024-11-29 12:33 | sebasjm | Assigned To | sebasjm => avalos |
| 2024-12-05 08:38 | avalos | Note Added: 0023794 | |
| 2024-12-05 08:41 | avalos | Note Added: 0023795 | |
| 2024-12-05 09:07 | Stefan | Note Added: 0023797 | |
| 2024-12-05 13:33 | bernaalp | Note Added: 0023799 | |
| 2024-12-05 13:36 | bernaalp | Note Edited: 0023799 | |
| 2024-12-05 13:38 | bernaalp | Note Edited: 0023799 | |
| 2024-12-10 14:37 | Stefan | Note Added: 0023848 | |
| 2024-12-11 13:27 | Christian Grothoff | Note Added: 0023858 | |
| 2024-12-12 22:01 | avalos | Status | assigned => informing |
| 2024-12-12 22:01 | avalos | Resolution | open => fixed |
| 2024-12-12 22:01 | avalos | Note Added: 0023877 | |
| 2024-12-13 00:59 | Christian Grothoff | Fixed in Version | => 0.14 |
| 2024-12-13 18:15 | Christian Grothoff | Status | informing => closed |