Latency message after streaming now reports with decimal point

[kentyman23]

The Show latency message after streaming toast previously reported truncated integers because integer division was used to calculate them (5.99 would be reported as 5). This led to inaccuracies reported here: https://docs.google.com/spreadsheets/d/1WSyOIq9Mn7uTd94PC_LXcFlUi9ceZHhRgk-Yld9rLKc/

Since we're using floating-point arithmetic, we no longer have to avoid divide-by-zero errors. Corner cases one might see are "∞ ms" (positive time divided by 0 frames) or "NaN ms" (0 time divided by 0 frames). I felt these were perfectly fine to output in these theoretical, degenerate cases. Because of this, I was able to simplify the logic in Game.onStop to no longer check for 0s. This simpler logic means we don't need both conn_client_latency_hw and conn_hardware_latency localized strings; I opted to remove the former and keep the latter and put a newline between them, as it was hard to quickly read both stats when the visual location of the values depended upon how the wrapping worked out. This is how it looks:

(Note that PR #1313 was abandoned after I realized I pushed to my fork's master instead of a branch.)

[cgutman]

Will this do the right thing for locales that use other separators (such as ,) for decimal values?

[kentyman23]

Great catch. I had assumed it would inherit the same local as getResources().getString(), but that may be wrong according to the docs:

To obtain a NumberFormat for a specific locale, including the default locale, call one of NumberFormat's factory methods, such as getInstance(). In general, do not call the DecimalFormat constructors directly, since the NumberFormat factory methods may return subclasses other than DecimalFormat. If you need to customize the format object, do something like this:

NumberFormat f = NumberFormat.getInstance(loc);
 if (f instanceof DecimalFormat) {
     ((DecimalFormat) f).setDecimalSeparatorAlwaysShown(true);
 }

Stay tuned for a fix...

[kentyman23]

Speaking of localization, I noticed in someone's Discord video that there are localized versions of the millisecond suffix that we sometimes use and sometimes don't:

I'll see if there is an existing string I can leverage instead of hardcoding it as we have been in this method.

[kentyman23]

Hmm, it appears I'd have to make a new localized string or edit the existing ones to be format strings. Am I allowed to change or add new strings, or is that discouraged because it breaks existing localization? Would it be better for me to surgically steal the localized string for the suffix (like that мс in the Russian(?) string above) so that we don't have to get the localizers to do another pass?

[kentyman23]

@cgutman, please let me know which way you'd prefer. The former seems more "correct", but the latter seems easier and probably safe.

[ReenigneArcher]

I'd have to make a new localized string

@kentyman23 I think this is the correct approach.

@cgutman I'm wondering how the translations are occurring. It seems like it's all manually done through regular PRs? I could set something up on CrowdIn like I do for LizardByte and Sunshine. I have a mono project on CrowdIn that handles all the translations for code projects https://crowdin.com/project/lizardbyte (and another for docs). If you select any language you can see how the translations are divided by GitHub repo and priority. CrowdIn is free for open source. I opted to put everything in one project for ease of management. Let me know if you want me to setup something similar for Moonlight projects.

Edit: I see that translations occur at https://hosted.weblate.org/projects/moonlight/moonlight-android/ ... is only the ./app/src/main/res/values/strings.xml supposed to be modified in git?