harmonize the use of ellipsis ("...") in the GUI #1211

Diapolo commented at 2:26 PM on May 6, 2012: none

use it in context / main menus, but not on buttons
update some strings to be clearer / more informative

luke-jr commented at 4:45 PM on May 6, 2012: member

How about using a proper ellipsis character ("…") while you're changing this?

gmaxwell commented at 6:14 PM on May 6, 2012: contributor

Putting utf-8 directly in the source is probably not a grand idea. I assume you can use an entity? e.g. & hellip;

laanwj commented at 6:36 PM on May 6, 2012: member

Unicode escapes such as \u20AC work in gcc, but I'm not sure it works in MSVC compilers. I'm not sure whether XML entities work, but I'm afraid not. Qt recommends manually appending QChar(xxx), but this will of course mess with translations as it cannot be in the Tr. It's unfortunate that non Latin-1 in source code is an impossibility even in 2012 :/

luke-jr commented at 6:42 PM on May 6, 2012: member

Can we use C++11?

laanwj commented at 6:45 PM on May 6, 2012: member

I'm sure this is not important enough to switch to a newer C++ standard. If this worries you I think the easiest way is to just use "..." in the source code, then in the English translation translate it as "…" (translator obviously has no problem with unicode). Then again... my font doesn't even show a difference between both...

Diapolo commented at 7:20 PM on May 6, 2012: none

Do I get an ACK for the idea and current places in the code, if yes I will start looking into usage of perhaps & hellip ;. If that does not work we should simply continue with "..." (3 points").

Diapolo commented at 7:54 PM on May 6, 2012: none

It is possible to use QString::fromUtf8("\u2026") in the code. Shall I use this?

Diapolo commented at 8:28 PM on May 6, 2012: none

See my last commit, if this gets your OK, I will introduce the use of ELLIPSIS where it's used in strings in the code. And rework that pull.

laanwj commented at 8:57 PM on May 6, 2012: member

I don't think you should \u2026 unless you verified it with the MSVC compiler (which, AFAIK, doesn't support UTF-8 escapes as I've said above). Which means you will end up with the equivalent \xe2\x80\xa6. Also, you should at least use trUtf8 so that you can use it in translated messages.

Diapolo commented at 9:03 PM on May 6, 2012: none

I can't verify it for MSVC, I can only try to investigate this via a web search :-/. Would it be possible to use a #ifdef for MSVC?

trUtf8 is not used, because I wanted to keep ELLIPSIS out of translations, so it wont ever show up on Transifex.

laanwj commented at 9:04 PM on May 6, 2012: member

I'd certainly keep all messages in their entirely in translations. If that's not possible, don't bother with this.

Diapolo commented at 9:08 PM on May 6, 2012: none

@laanwj So it would be best to simply keep "..."! Do you agree to the other changes (no "..." on buttons, but in menus)? If yes I will revert the last ELLIPSIS commit and this is finished.

laanwj commented at 9:11 PM on May 6, 2012: member

Yes, it's fine then.

Diapolo commented at 9:15 PM on May 6, 2012: none

Reverted and finished!

Diapolo commented at 8:52 PM on May 8, 2012: none

Rebased, no code changes!

harmonize the use of ellipsis ("...") to be used in menus, but not on buttons / update some strings to be more informative 50a3855082

in src/qt/transactionview.cpp:None in 94b3ca4c8c outdated

  57 | @@ -58,7 +58,7 @@
  58 |      dateWidget->addItem(tr("This month"), ThisMonth);
  59 |      dateWidget->addItem(tr("Last month"), LastMonth);
  60 |      dateWidget->addItem(tr("This year"), ThisYear);
  61 | -    dateWidget->addItem(tr("Range..."), Range);
  62 | +    dateWidget->addItem(tr("Range"), Range);

laanwj commented at 6:43 AM on May 9, 2012:

I'm not sure I agree with removing this. The "..." here imply that more information is going to be asked (ie, beginning and end of range).

Diapolo commented at 6:45 AM on May 9, 2012:

I changed this, because you CAN add information / change it, but you do not need to (not mandantory)!

laanwj commented at 6:52 AM on May 9, 2012:

Sure, it's never mandatory, but makes sense... all the other options are well-defined in themselves but a range is not.

Diapolo commented at 7:05 AM on May 9, 2012:

Will revert so this can be merged!

Diapolo commented at 7:08 AM on May 9, 2012: none

Revert -> "Range" is now "Range..." again.

laanwj referenced this in commit e17018adcd on May 9, 2012

laanwj merged this on May 9, 2012

laanwj closed this on May 9, 2012

coblee referenced this in commit 5145d2b8dd on Jul 17, 2012

suprnurd referenced this in commit fa301ecb49 on Dec 5, 2017

lateminer referenced this in commit a29ff22444 on Jan 22, 2019

lateminer referenced this in commit a2912a9d62 on Jan 10, 2020

DrahtBot locked this on Sep 8, 2021