gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[taler-docs] branch master updated: clarifications


From: gnunet
Subject: [taler-docs] branch master updated: clarifications
Date: Sun, 08 Oct 2023 20:14:26 +0200

This is an automated email from the git hooks/post-receive script.

marc-stibane pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new 5eae6c7c clarifications
5eae6c7c is described below

commit 5eae6c7ceb4f8ac9a228014b41ba26f885b15f34
Author: Marc Stibane <marc@taler.net>
AuthorDate: Sun Oct 8 20:14:18 2023 +0200

    clarifications
---
 design-documents/051-fractional-digits.rst | 47 ++++++++++++++++++++++--------
 1 file changed, 35 insertions(+), 12 deletions(-)

diff --git a/design-documents/051-fractional-digits.rst 
b/design-documents/051-fractional-digits.rst
index 15784a85..cd2e1eb3 100644
--- a/design-documents/051-fractional-digits.rst
+++ b/design-documents/051-fractional-digits.rst
@@ -23,26 +23,33 @@ There is already a specification for ScopedCurrencyInfo - 
this needs to change
 
 We need three core characteristics for fractional digits for each currency:
 
-a) the number of fractional digits [0..8] the user may enter in a 
TextInputField
+e) the number of fractional digits e in [0..8] the user may 'e'nter in a 
TextInputField
 
-b) the number of fractional digits [0..8] to be rendered as normal characters 
(same font and size as the integer digits).
+n) the number of fractional digits n in [0..8] to be rendered as 'n'ormal 
characters (same font and size as the integer digits).
    All additional fractional digits will be rendered as SuperScriptDigits as 
known from gas filling stations.
    The UI should never round or truncate any amount, but always render all 
existing digits (except trailing zeroes, see c).
 
-c) the number of fractional digits [0..8] to be rendered as trailing zeroes 
(including SuperScript digits).
-   E.g. if this is 2 (and normal == 2), then render $5 as “$ 5.00”.
-   If this is 3 (and normal == 2), then render $5 as “$ 5.00⁰” with two normal 
trailing zeroes and one superscript trailing zero.
+z) the number of fractional digits z in [0..8] to be rendered as trailing 
'z'eroes (including SuperScript digits).
+   E.g. if z = 2 (and n = 2), then render $5 as “$ 5.00”.
+   If z = 3 (and n = 2), then render $5 as “$ 5.00⁰” with two normal trailing 
zeroes and one superscript trailing zero.
 
-Usually, all these three numbers have the same value, which means that in case
-of e.g. “2” (used for €,$,£) the user can enter cent/penny values (but not a
-fraction of those), these cents/pennies are always shown (even if they are 0)
-as two normal digits after the decimal separator, and fractions of a
-cent/penny are rendered as SuperScriptDigits, but only if they are not
+The values e, n, and z are independent from each other. Each could be any value
+from 0 to 8. However, when a user enters an amount, s/he should be able to 
input
+all normal fractionals. Thus e should never be smaller than n.
+
+Usually, all these three numbers have the same value (e = n = z), which means
+that in case of e.g. “2” (used for €,$,£) the user can enter cent/penny values
+(but not a fraction of those), these cents/pennies are always shown (even if
+they are 0) as two normal digits after the decimal separator, and fractions of
+a cent/penny are rendered as SuperScriptDigits, but appear only if they are not
 trailing zeroes.
+For japanese ¥, all three values could be 0, which means that the user cannot
+enter fractionals at all. Fractions would never be rendered as normal digits
+but always as SuperScript, and appear only if they are not trailing zeroes.
 
 Additionally, some cryptocurrencies have such huge units, that they are
 commonly rendered in milli-units, such as mBTC (milliBTC, 1/1000 of a BTC),
-Gwei (Giga-WEI), MWei (Million-WEI), Kwei (Kilo-WEI), or
+Gwei (Giga-WEI), Mwei (Million-WEI), Kwei (Kilo-WEI), or
 Mether/Kether/Gether/Tether and more "logical" units such as Szabo and
 Finney. See `https://coinguides.org/ethereum-unit-converter-gwei-ether/` if
 you want a good laugh. Regardless of the self-inflicted insanity here, this
@@ -55,7 +62,11 @@ iOS has a built-in currency formatter, which knows how to 
deal with
 thousands-separators and where to apply them (e.g. India uses a mixture of
 hundreds and thousands instead of putting the separator after each 3 digits
 like western currencies).  However, this formatter will round after two (or
-three) fractional digits and thus cannot be used for the whole amount.
+three) fractional digits and thus cannot be used for the whole amount. But it
+could be used to convert the integer part plus the fractional part to be
+rendered as normal digits (n) into a string, and then remaining fractional
+digits (if not zero, or if trailing SuperScript zeroes should be shown)
+could be added as SuperScript digits to this formatted string.
 
 (please add information about Android and WebEx here)
 
@@ -199,4 +210,16 @@ Drawbacks
 Discussion / Q&A
 ================
 
+We probably should NOT have the decimalSeparator in this definition. Instead 
that
+should be taken from the locale of the user, so they see currency amounts 
formatted
+like they're used to.
+If we really keep this, then we would also need the thousandsSeparator to 
ensure it is
+not identical to the decimalSeparator.
+Better to leave this can of worms to the operating system our app runs on, and 
render
+according to the user's preferences (locale)...
+
+However, instead of decimalSeparator we could specify the locale this currency 
belongs to.
+
+
+
 (This should be filled in with results from discussions on mailing lists / 
personal communication.)

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]