MelvinBot
commented
2 years ago Triggered auto assignment to @roryabraham (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.
Closed kavimuru closed 2 years ago
MelvinBot
commented
2 years ago Triggered auto assignment to @roryabraham (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.
MelvinBot
commented
2 years ago Triggered auto assignment to @bfitzexpensify (External), see https://stackoverflow.com/c/expensify/questions/8582 for more details.
bfitzexpensify
commented
2 years ago Posted to Upwork - job
MelvinBot
commented
2 years ago Triggered auto assignment to @parasharrajat (Exported)
MelvinBot
commented
2 years ago Triggered auto assignment to @Luke9389 (Exported), see https://stackoverflow.com/c/expensify/questions/7972 for more details.
anthony-hull
commented
2 years ago I will format the value of this.state.amount https://github.com/Expensify/App/blob/96ba12da431936b19c80eb895f9531ee44039e71/src/pages/iou/steps/IOUAmountPage.js#L196 in WithLocalise
props.numberFormat(
this.state.amount
{options},
);
parasharrajat
commented
2 years ago @anthony-hull Thanks for the proposal. How would you solve the first screen issue?
I feel that it would inconsistent for the Request Money screen if the user types . from the keypad and , is added on the screen. What do you think @Luke9389 ?
railway17
commented
2 years ago I am submitting this proposal because I've got an email that was allowed to be hired for another jobs by this pull request approval
I was able to reproduce this issue in Web and Android versions and absolutely sure that this issue will also occur on other platforms.
I am attaching my replication screenshots to let you understand easier (but screenshots are displaying some HTTP requests).
Mainly, we have 2 problems that are related to this issue.
PROBLEM 1 is the WRITING and DISPLAYING issue in the IOUAmountPage (It is used to enter the Split or Request values).
For now, the current code only allows to enter normal number format by following methods:
validateAmount(amount) {
const decimalNumberRegex = new RegExp(/^\d+(,\d+)*(\.\d{0,3})?$/, 'i');
return amount === '' || (decimalNumberRegex.test(amount) && (parseFloat((amount *
100).toFixed(3)).toString().length <= CONST.IOU.AMOUNT_MAX_LENGTH));
}
stripCommaFromAmount(amount) {
return amount.replace(/,/g, '');
}We can easily update this module in order to display es format numbers too.
But is suggested to keep the normal number format when it is saved. So I am going to fix it for only displaying value.
PROBLEM 2 is GETTING and DISPLAYING in the ReportTransaction, IOUPreview and IOUQuote components.
Because these values are displayed by Onyx and persistent storage without any conversion but this data is only saved in normal number format. So number format is not changed even though we change the locale.
While researching, I noticed also another problem regarding this issue.
Requested {currency}{number} from {name} string is also taken from storage, but there is not any conversion module or Localization keys for these words.
I think it is not recommended way to save the values with formatted and is better to reformat the values before displaying in the frontend (after getting the values from storage).
//define state like this.//update validate rule validateAmount(amount) {
return enFormattedAmount === '' || (decimalNumberRegex.test(enFormattedAmount) && (parseFloat((enFormattedAmount * 100).toFixed(3)).toString().length <= CONST.IOU.AMOUNT_MAX_LENGTH)); }
stripCommaFromAmount(amount) {
//format saving values to normal number format
<Button
success
style={[styles.w100, styles.mt5]}
- **PROBLEM 2:** Let me describe how to fix with the `ReportTransaction` component as an example.
Because we can use the same conversion method in the 3 parts, I am defining the conversion method in the `libs/reportUtils.js`. And will display the converted values by using this conversion method.
```diff
//ReportTransaction.js
+ import compose from '../libs/compose';
+ import withLocalize from './withLocalize';
+ import * as ReportUtils from './../libs/reportUtils'
---
<Text style={[styles.chatItemMessage]}>
- {this.props.action.message[0].text}
+ {ReportUtils.changeNumberFormatFromMessage(this.props.action.message[0].text, this.props.numberFormat)}
</Text>
---
-export default withOnyx({
- transactionsBeingRejected: {
- key: ONYXKEYS.TRANSACTIONS_BEING_REJECTED,
- },
-})(ReportTransaction);
+export default compose(
+ withLocalize,
+ withOnyx({
+ transactionsBeingRejected: {
+ key: ONYXKEYS.TRANSACTIONS_BEING_REJECTED,
+ },
+ }),
+)(ReportTransaction);
// libs/reportUtils.js
+ function changeNumberFormatFromMessage(messageText, changeNumberFormat) {
+ const numRegex = new RegExp(/[\d,]+[\.\d+]*/g);
+ const matches = messageText.match(numRegex)
+ if (matches) {
+ const matchStrNum = matches[0].replace(/,/g, '');
+ const formattedNumber = changeNumberFormat(matchStrNum);
+ messageText = messageText.replace(numRegex, formattedNumber);
+ }
+ return messageText
+ }
Well.. @bfitzexpensify
I tried to submit my proposal in upwork but got a strange issue.
It is not loaded while loading send proposal page.
Sometimes it is loaded but Terms form is different from another jobs and can't submit.
Maybe, is it related open jobs that I worked for Magnifying icon issue? Even though I've got the pull request approval and email, still can't send new proposal?
Please help me how can I do
parasharrajat
commented
2 years ago Looking at the proposals....
roryabraham
commented
2 years ago @railway17 I really liked your thorough summary of the problems, but wasn't a big fan of your proposal for a few reasons:
That said, here are some high-level goals we should strive for in a solution for this issue:
Requested $10.50 from Rajat. Instead, just store the number 10.50, and localize it before displaying it.BigNumberPad and IOUAmountPage should be localized as well, such that if the locale is es then a user cannot manually enter a ., just as they cannot manually enter a , in the components' current forms.
Luke9389
commented
2 years ago I think we're still looking for a proposal that can encapsulate the points that @roryabraham has mentioned above. Maybe we need a localNumber component or something like that to use.
railway17
commented
2 years ago 3. concise Thank you for your explain, @roryabraham Let me rewrite the solution with the summary. As I mentioned, we need to resolve 2 kinds of problems at this issue.
- Resolve the WRITING and DISPLAYING issue in the
IOUAmountPageandBigNumberPad. It can be resolved by updating thevalidateAmountandstripCommaFromAmountmethods inIOUAmountPage.js
GETTING and DISPLAYING issue in the ReportTransaction, IOUPreview, and IOUQuote pages.
As I mentioned, we need to display numbers before displaying them on these pages because values are saved in US format in the Onyx.
But for now, those are displaying without any conversion like below:
...
{Str.htmlDecode(fragment.text)}
...
props.iouReport.cachedTotal ? props.iouReport.cachedTotal.replace(/[()]/g, '') : '';
...
{this.props.action.message[0].text}
...For the @parasharrajat 's comment, let me describe my idea.
I am not sure how Spaineses are typing numbers.
The problem might occur when they enter long numbers such as 123. 234,56, 34. 252. 323,98... in IOUAmountPage.
I think we should allow type , they want to enter float value.
I don't think it is not recommended way to click the , key if they want to enter . or click . if they want to enter ,.
For the Requested {number} from {name} string issue, it wasn't reported in this issue.
Actually, I also think we don't need to save the strings in the Onyx but those are saved now. So, I reported for it in my above proposal. I think Expected Result should be updated or New Issue should be created for this problem.
Thank you.
parasharrajat
commented
2 years ago I agree with @roryabraham points. Although the proposal touches most of the code but does not explain it clearly. I also think,
if (this.props.preferredLocale == 'es') {
+ enFormattedAmount = amount.replace(/\./g, '').replace(/,/g, '.');
+ }we don't do this. The app is not specifically configured for Spanish. There could be many languages. The solution should work with any language that we have or add in the future. for this purpose, we have withLocalize HOC.
The problem might occur when they enter long numbers such as 123. 234,56, 34. 252. 323,98... in IOUAmountPage. I think we should allow type , they want to enter float value. I don't think it is not recommended way to click the
,key if they want to enter.or click.if they want to enter,.
I think, we are not concerned with the number of segments ATM. Only the decimal part matters. it's totally fine that if you enter 123456.34 and it is shown as 123,456.34 in other parts of the app. But if the decimal is presented as , instead of . it becomes an issue. For E.g. Spanish user typing 123.456 then it's not ~~ 123 instead he would parse it as 123 thousand 4 hundred fifty-six but in real our app would take that as 1 hundred twenty-three point 46. This is a big transactional issue.
parasharrajat
commented
2 years ago We should not store any numeric values within formatted strings in Onyx, because that would prevent us from being able to localize those numbers easily. i.e: don't store Requested $10.50 from Rajat. Instead, just store the number 10.50, and localize it before displaying it. For the Requested {number} from {name} string issue, it wasn't reported in this issue.
I think we had another issue to localize IOU strings. cc: @iwiznia
iwiznia
commented
2 years ago I agree that onyx should not save localized data. Not sure what other issue you are referring to, I think you might be thinking about the messages that are generated in the backend? (which we are not localizing now)
railway17
commented
2 years ago I agree that onyx should not save localized data. Not sure what other issue you are referring to, I think you might be thinking about the messages that are generated in the backend? (which we are not localizing now)
Yes, I think these messages are generated from the backend.
iwiznia
commented
2 years ago Any texts coming from the server can remain unlocalized, since we yet have to add support for localization in the server, for now only the frontend has the framework to localize things.
railway17
commented
2 years ago So, I have also reported converting the text before displaying it in the frontend (after getting data from Onyx).
bfitzexpensify
commented
2 years ago @parasharrajat what's the status here? Is here @railway17's proposal good, does it need further work, or shall I increase the price for this issue?
parasharrajat
commented
2 years ago @bfitzexpensify First we need to redefine the scope of this issue. Based on the latest comment https://github.com/Expensify/App/issues/6427#issuecomment-982662634, What should be the new expected behaviour here? Not sure whom to tag here but @Luke9389 Could you please point out which part do we need to fix out of the posted screens in the description?
Secondly, Railways proposal is still lacking proper details. He would need to rephrase his proposal after we refine the scope here.
There is an open question here https://github.com/Expensify/App/issues/6427#issuecomment-979227780. I am not sure what is decided for that.
I don't think it is not recommended way to click the , key if they want to enter . or click . if they want to enter ,.
Not sure what is proposed here.
roryabraham
commented
2 years ago Chatted with @Luke9389 1:1 and he'll be the CME on this issue going forward. Thanks Luke!
Luke9389
commented
2 years ago Question, are we sure we want to report USD using commas? It seems like the notation for the amount should be set by the currency, not by the language. If we were requesting a number of pesos, then I'd expect a comma. Right?
iwiznia
commented
2 years ago It seems like the notation for the amount should be set by the currency, not by the language. If we were requesting a number of pesos, then I'd expect a comma. Right?
Nope. The decimal separator is tied to the language you are writing in, not the language that's used in the country were the currency was created.
bfitzexpensify
commented
2 years ago Haven't had any action here for a while. Reposted the job here (editing in Upwork is broken at the moment) and raised price to $1000
railway17
commented
2 years ago Hi, @iwiznia, @bfitzexpensify If you still dislike my proposal, I would like to confirm again.
I am writing the number conversion below, please make sure it is correct.
123, 456, 678.89 -> 123. 456. 678,89
12.36->12,36
While entering a comma in the IOU, it should be displayed as a dot instantly unless it is float point? So even though I typed 123, 456, 235, then it should be displayed 123. 456. 235?
And it should not be displayed as comma even though user typed a dot in the float point?
ex: typed 12.25 -> 12.25.
For question 2, please make sure whether it should be instant conversion or not.
Actually, I think nobody knows clearly about this action logic here.
parasharrajat
commented
2 years ago Luke is probably on leave but here are a few questions before I review the proposals. https://github.com/Expensify/App/issues/6427#issuecomment-989201104
iwiznia
commented
2 years ago IMO the expected behavior is that the keyboard and the amount show , instead of . if your language's decimal separator is ,. Not sure about the keyboard, but for showing the amount correctly, that is all handled by the existing number formatting functions.
railway17
commented
2 years ago IMO the expected behavior is that the keyboard and the amount show
,instead of.if your language's decimal separator is,. Not sure about the keyboard, but for showing the amount correctly, that is all handled by the existing number formatting functions.
Btw, it doesn't a little complex.
Because we might use , keyboard while sending messages in chat, it is a little confusable.
Let's assume that we are sending message like Hi, XXX! I've sent $12, 322, 23.12 to you in the chatbox.
Even though we are discussing about IOU board, we can assume this case.
In this case, there maybe some other complex problems if you have to change the , and . in realtime.
Because of this reason, I was asking to make sure logic again.
iwiznia
commented
2 years ago I am very confused by your message. This issue applies to where we display or input an amount. If you are writing text on the chat, we won't do anything and send the message as you wrote them, without any processing or change.
songlang1994
commented
2 years ago I submit my proposal try to summarize this issue. Hope to make it more clear.
We're discussing the numbers format, especially the decimal point, which can appear in several different places.
Numbers for internal storage we use a dot (".") as decimal point, never add any thousandth separator, and only keep the significant digits.
Examples:
"1"
"23456.99"
"19940910.996996"This format is able to be parsed by JavaScript engine or other decimal libs, such as bignumber.js. I'd like to call this format as "normalized format".
Numbers should be transformed to the localized format before displaying on UI.
Examples:
"1200.5" -> "1,200.50" (English)
"1200.5" -> "1.200,50" (Spanish)Digits (0-9) and the decimal point (".") should be displayed in localized format on the keypad. So the keypad in Spanish environment should looks like:
|------|------|------|
| 1(1) | 2(2) | 3(3) |
|------|------|------|
| 4(4) | 5(5) | 6(6) |
|------|------|------|
| 7(7) | 8(8) | 9(9) |
|------|------|------|
| ,(.) | 0(0) | <(\b)|
|------|------|------|The leading character is used to display on UI. The character in brackets will be the input event value when user touch the key, they should be stable regardless of any language environment. Therefore, when a Spanish user touch the "," key on the keypad, the app still recognizes that the user has input a "." character.
| User Input | UI Display (English) | UI Display (Spanish) | Internal Storage |
|---|---|---|---|
| 1 | 1 | 1 | 1 |
| 12 | 12 | 12 | 12 |
| 120 | 120 | 120 | 120 |
| 1200 | 1,200 | 1.200 | 1200 |
| 1200. | 1,200. | 1.200, | NaN |
| 1200.5 | 1,200.5 | 1.200,5 | 1200.5 |
| 1200.50 | 1,200.50 | 1.200,50 | 1200.5 |
This above way is good enough for the mobile app which uses the virtual keypad. But for the desktop app, users will input numbers directly from the hardware keyboard. In this case, we should have 2 options:
I'd prefer the option 2 if it's possible to implemente since it's a more localized approach.
parasharrajat
commented
2 years ago Great explanation @songlang1994.
The leading character is used to display on UI. The character in brackets will be the input event value when users touch the key, they should be stable regardless of any language environment. Therefore, when a Spanish user touches the "," key on the keypad, the app still recognizes that the user has input a "." character.
This is what is needed for this issue.
3.3 Input from hardware keyboard
I don't think we need to worry about this. Hardware keyboards or virtual keyboards use standard keys and I think they will work just fine.
Do you have a proposal to fix the problem explained above?
songlang1994
commented
2 years ago @parasharrajat My proposal.
Add translation for BigNumberPad. Currently I think just translate the decimal point is well enougth to match the requirement.
// File: src/languages/en.js
+ bigNumberPad: {
+ decimalPoint: '.',
+ },
// File: src/languages/es.js
+ bigNumberPad: {
+ decimalPoint: ',',
+ },
// File: src/components/BigNumberPad.js
<Button
key={column}
style={[styles.flex1, marginLeft]}
- text={column}
+ text={column === '.' ? this.props.translate(`bigNumberPad.decimalPoint`) : column}
onLongPress={() => this.handleLongPress(column)}Localize amount before passing into TextInputAutoWidth
// File: src/pages/iou/steps/IOUAmountPage.js
+ get localizedInputingAmount() {
+ if (!this.state.amount) {
+ return '';
+ }
+
+ const endsWithDecimalPoint = this.state.amount.endsWith('.');
+ if (endsWithDecimalPoint) {
+ const localized = this.props.numberFormat(this.state.amount, {useGrouping: false, minimumFractionDigits: 1});
+ return localized.slice(0, -1);
+ }
+
+ const fraction = this.state.amount.split('.')[1];
+ const fractionDigits = fraction ? fraction.length : 0;
+ return this.props.numberFormat(this.state.amount, {useGrouping: false, minimumFractionDigits: fractionDigits});
+ }
- updateAmount(amount) {
- if (!this.validateAmount(amount)) {
- return;
- }
-
- this.setState({amount: this.stripCommaFromAmount(amount)});
- }
+ // Handle each input data instead of accepting the whole string from TextInput.
+ // This is a simple implemention which can not handle some special cases,
+ // such as pasting from clipboard.
+ updateAmount({nativeEvent: {data}}) {
+ this.updateAmountNumberPad(data || '<');
+ }
render() {
return (
...
<TextInputAutoWidth
...
- onChangeText={this.updateAmount}
+ onChange={this.updateAmount}
- value={this.state.amount}
+ value={this.localizedInputingAmount}
...
/>
...
)
}I don't think we need to worry about this. Hardware keyboards or virtual keyboards use standard keys and I think they will work just fine.
Maybe we do need to transform the decimal point from users input.
In the video "hardware-keyboard.mp4" above, UI shows the localized format number "12,99" but actually I typed:
"1" -> "2" -> "." -> "9" -> "9"Because I am an English user and I am used to type "." as the decimal point. I think a real Spanish native user will type
"1" -> "2" -> "," -> "9" -> "9"yeah, that becomes another issue. We are only working on US layouts and expect users to type in US layouts. So if he types , instead of .. This is probably going to be trimmed. but if we types . then it would be converted to ,.
This becomes a complicated problem. We are not only supporting Spanish. We will have other languages as well. So this solution will not be a generic one.
@iwiznia Do you have some comments about it? Also, are we planning to localize the IOU strings as well shown in screenshots?
songlang1994
commented
2 years ago yeah, that becomes another issue. We are only working on US layouts and expect users to type in US layouts. So if he types
,instead of.. This is probably going to be trimmed. but if we types.then it would be converted to,.
It's not really so complicated. The process of handling keyboard input is very clear:
Please take a look at the screenshots first. If it's the expected behavior that you really want to achieve, I have a more general proposal.
TL;DR
1) Instead of translate decimal point mannually, create a new LocaleDigitUtils.js. It will manage the relation between localized format digits and standard format digits.
// File: src/libs/LocaleDigitUtils.js
import invariant from 'invariant';
import _ from 'underscore';
import numberFormat from './numberFormat';
const DECIMAL_SEPARATOR = '.';
function getLocaleDigits(locale) {
const localeDigits = [];
for (let i = 0; i <= 9; i++) {
localeDigits.push(numberFormat(locale, i));
}
// The last element is decimal separator
localeDigits.push(numberFormat(locale, 1.5)[1]);
return localeDigits;
}
function isValidLocaleDigit(locale, digit) {
return getLocaleDigits(locale).includes(digit);
}
function toLocaleDigit(locale, digit) {
const localeDigits = getLocaleDigits(locale);
if (digit === DECIMAL_SEPARATOR) {
return localeDigits[10];
}
const index = Number(digit);
invariant(index >= 0 && index <= 9, `${digit} must be in "0~9" or "."`);
return localeDigits[index];
}
function fromLocaleDigit(locale, localeDigit) {
const index = _.findIndex(getLocaleDigits(locale), it => it === localeDigit);
invariant(index > -1, `${localeDigit} is not a valid locale digit`);
return index < 10 ? index.toString() : DECIMAL_SEPARATOR;
}
export {
isValidLocaleDigit,
toLocaleDigit,
fromLocaleDigit,
};2) Translate every digits including the decimal point in BigNumberPad.
// File: src/components/BigNumberPad.js
<Button
key={column}
style={[styles.flex1, marginLeft]}
- text={column}
+ text={column === '<' ? column : this.props.toLocaleDigit(column)}
onLongPress={() => this.handleLongPress(column)}3) Localize amount before pass into TextInputAutoWidth, this step is basically same as I described in https://github.com/Expensify/App/issues/6427#issuecomment-1003303248 except adding a extra transform from hardware keyboard input.
// File: src/pages/iou/steps/IOUAmountPage.js
updateAmount({nativeEvent: {data}}) {
if (!data) {
this.updateAmountNumberPad('<');
} if (this.props.isValidLocaleDigit(data)) {
// Transform the locale digits that user input to "standard" digits
this.updateAmountNumberPad(this.props.fromLocaleDigit(data));
} else {
// Ignore non-digit keys
}
}To give a obvious example, I show an Arabic example in the screenshots. In order to input numbers with hardware keyboard, I've switched my input source to Arbic layout first.
parasharrajat
commented
2 years ago I understood what you are trying to achieve here. Basically, something related to what I was thinking to be done for this. It covers the broach picture as well. But I would have to discuss this issue internally to understand what is included in the scope of this issue. This is something I am not yet fully clear about.
Thanks for paying attention to the hardware keyboard as well. I think we will have to manage that as well. So +1 for that.
mdneyazahmad
commented
2 years ago I will create a function to get decimal symbol used in the current locale. We can attach this function in the LocaleProvider.
getDecimalSymbol() {
const formattedNumber = this.props.numberFormat(1.1);
const localized1 = this.props.numberFormat(1);
const numberReplaceRegExp = new RegExp(localized1, 'g')
return formattedNumber.replace(numberReplaceRegExp, '');
}It won't make any changes in the current state. It is just to show the formatted number in the ui, internally we will have our numbers in the us locale.
getFormattedAmount(amount) {
if(!amount) {
return '';
}
let formattedAmount = this.props.numberFormat(amount, {
useGrouping: false,
});
if(amount.endsWith('.')) {
formattedAmount += this.getDecimalSymbol();
}
return formattedAmount;
}<TextInputAutoWidth
inputStyle={styles.iouAmountTextInput}
textStyle={styles.iouAmountText}
onChangeText={this.updateAmount}
ref={el => this.textInput = el}
+ value={this.getFormattedAmount(this.state.amount)}
- value={this.state.amount}
placeholder="0"
keyboardType={CONST.KEYBOARD_TYPE.NUMERIC}
showSoftInputOnFocus={false}
inputmode="none"
/>
I will map the us format locale to the current locale number in the number pad.
+import withLocalize, {withLocalizePropTypes} from './withLocalize';
+import compose from '../libs/compose';
getLocalizedChar(char) {
if(char == '.') {
return this.getDecimalSymbol();
}
if(!isNaN(char)) {
return this.props.numberFormat(char);
}
return char;
}
<Button
key={column}
style={[styles.flex1, marginLeft]}
- text={column}
+ text={this.getLocalizedChar(column)}
onLongPress={() => this.handleLongPress(column)}
onPress={() => this.props.numberPressed(column)}
onPressIn={ControlSelection.block}
onPressOut={() => {
clearInterval(this.state.timer);
ControlSelection.unblock();
}}
/>+ export default compose(withLocalize)(BigNumberPad);
- export default BigNumberPad;@Luke9389 @iwiznia Awaiting comments https://github.com/Expensify/App/issues/6427#issuecomment-1003364632
Are we planning to localize the IOU strings shown in the screenshots as part of this issue?
mdneyazahmad
commented
2 years ago @parasharrajat As I proposed in my proposal https://github.com/Expensify/App/issues/6427#issuecomment-1003706648 Maybe, this can solve this issue.
Display Number We will store all number in us locale, because Intl.NumberFormat can be used to convert all us locale based number to other.
Get number from keyboard ui We will display the localized number in the numberpad however it will have values in us locale.
Get input from keyboard We will accept the number but when user enter , or . We will check it whether it is a decimal symbol (create helper function to get decimal symbol in current locale) and this will be stored as . in all cases.
iwiznia
commented
2 years ago Are we planning to localize the IOU strings shown in the screenshots as part of this issue?
If you are referring to the comment you see in the chat after doing the request, which is generated in the server, then no.
I don't like @songlang1994's proposal of putting the decimal and thousand separator in the translation files, mostly because they are already defined inside Intl.NumberFormat. The proposal from @mdneyazahmad is a bit better, but kind of odd too, I would recommend using formatToParts and passing a number like 1.10, then grab the part that have type set to decimal.
Regarding the big number pad UI, I agree it should display only the decimal separator of the current locale (grabbed using the method described in the paragraph above).
Regarding the physical keyboard, nothing needs to be done there, if you type a number, it shows up, if you type your locale's decimal separator it will add it and if you type anything else, then nothing should happen.
As for how we return the value to a component using the BigNumberPad, it should always be as a number, not as a string formatted number.
songlang1994
commented
2 years ago @iwiznia I've post a new implement above which use Intl.NumberFormat to grab the locale digits. See LocaleDiditUtils in this comment. https://github.com/Expensify/App/issues/6427#issuecomment-1003589574
It's just a demo so I didn't optimize the performance yet.
iwiznia
commented
2 years ago Oh, I think I missed that one, sorry. Did not even think about other numbers like arabic. I think that proposal is good, but will let @parasharrajat and @Luke9389 have the final say, since they are assigned.
parasharrajat
commented
2 years ago Thanks for the input @iwiznia.
If you are referring to the comment you see in the chat after doing the request, which is generated in the server, then no.
Based on this, We won't update the message that is coming from the backend in https://user-images.githubusercontent.com/43996225/143068980-41848fd5-bc85-4b2b-9a6b-1315610211ff.jpg.
But some parts of it can be localized such as IOU Preview and Header of Split Page. @songlang1994 your proposal is good for BigNumberpad but could you please add more details for these changes as well.
Thanks for your patience and for helping us understand your proposal.
Luke9389
commented
2 years ago First of all, I'd like to thank @songlang1994 for helping us clear this up in this comment.
@parasharrajat has a good point. So far, we haven't addressed how we will localize numbers that are coming from the back-end. I'm assuming @songlang1994 would want to use LocaleDigitUtils for this.
@songlang1994, would you be willing to show a proposal for how that would work? Thanks for your patience. I think we're almost there.
songlang1994
commented
2 years ago The messages from API are actually TEXT rather than numbers. So I think the localization process should be taken care of by the server.
BTW, IOUPreview re-format the amount TEXT by replacing brackets which may not be a nice way. It might be better to contact the back-end team and ask them to handle it.
// File: src/components/ReportActionItem/IOUPreview.js
// The original `cachedTotal` from API was something like "(HK$63.69)".
// `IOUPreview` convert it to "HK$63.69".
const cachedTotal = props.iouReport.cachedTotal ? props.iouReport.cachedTotal.replace(/[()]/g, '') : '';
parasharrajat
commented
2 years ago yeah, IOUQuote is populated from the backend and we can skip that for now. But we can still change the IOUPreview amount and currency. Look at the IOUBadge for this.
And there is one more screen that needs to be localized the header of
It would be great if you can submit a finalized proposal in one place so that others are aware of it.
But Overall, I like @songlang1994 's proposal.
cc: @Luke9389
:ribbon: :eyes: :ribbon: C+ reviewed
Luke9389
commented
2 years ago We're hoping to do localization entirely on the front end. @songlang1994, would you be willing to post the exact response the server is giving? Is it literally returning "Requested HK$12.88 from Test"? If so, maybe we should change the return to be an object, like
{
type: request,
amount: 12.58,
actor: Test
}That way the front end can localize it more easily.
Luke9389
commented
2 years ago Yep, I'm in the same boat as @parasharrajat. I'm ready to give the green light to @songlang1994 once a final proposal with all front end screens is submitted. It's OK to skip IOUQuote for now. It's a bit out of scope for this issue.
songlang1994
commented
2 years ago Is it literally returning "Requested HK$12.88 from Test"?
@Luke9389 Yes. The data from server related to IOUQuote is
"message": [
{
"type": "COMMENT",
"html": "Requested HK$12.58 from Test",
"text": "Requested HK$12.58 from Test",
"isEdited": false
}
],
If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!
Action Performed:
Expected Result:
All money amounts are localized to Spanish, comma as decimal separator. Eg: C$ 23,85
Actual Result:
Decimal separators are not localized in some screens. They are shown as English, in dots. Eg: C$ 23.85
Workaround:
Unknown
Platform:
Where is this issue occurring?
Version Number: 1.1.16-1 Reproducible in staging?: Yes Reproducible in production?: yes Logs: https://stackoverflow.com/c/expensify/questions/4856 Notes/Photos/Videos:
Expensify/Expensify Issue URL:
Issue reported by: Applause Slack conversation:
View all open jobs on GitHub