RetroArch
RetroArch copied to clipboard
Change 'Ago' last played style to 'Approximate time since'
… and use SI unit symbols instead of singular/plural words
Description
#14086 added a new style for the 'Last Played' display, which is undeniably great! Unfortunately, the name of the option, 'Ago', is very non-descriptive, so I propose 'Approximate time since' instead...
... oh, and also, the added texts are an ABSOLUTE NIGHTMARE localize:
- the number, unit, and 'ago' word (e.g. '33 seconds ago') all separately hold a fixed position - RIP all languages requiring a different sentence structure
- the feature was implemented to use singular form for 1 and plural for all other numbers, the English standard - RIP all languages having more plural forms or different requirements for it
Now, fixing 1. isn't terribly difficult, but 2. is a whole other beast (see this and weep, mortals).
Soooo, I would like to completely side-step the nightmare which is localized plurals by using SI unit symbols instead of written out words. I could not find what the SI symbols for week and month would be, but it should still be plenty readable enough, imo.
Reviewers
@sonninnos @IlDucci
Hmm, why not both instead of replacing it, since it removes weeks and months.. And surely the problematic languages can be dealt with somehow when and if needed, since they are the minority. Like simply making the option unavailable if the translation is impossible.
This is an issue that's been faced and tackled by a number of software projects before us, such as this one: https://timeago.org/. Is there a reason we can't solve it similarly? or even adapt our implementation to use existing translations directly? https://github.com/hustcc/timeago.js/blob/master/src/lang/he.ts
At the very least, if singular/plural is such a problem, we could always avoid singulars altogether and only switch to the next unit when we pass >=2 of the next unit. E.g., use minutes from 2-119 and switch to hours on 120 min; use hours from 2-47 and switch to days on 48 hrs; use days on 2-13 and switch to weeks on day 14; etc.
Isn't 'approximate time since' kinda too technical? Like 'Ago' seems to just roll better off the tongue and is less obfuscatory in language.
This is an issue that's been faced and tackled by a number of software projects before us, such as this one: https://timeago.org/. Is there a reason we can't solve it similarly? or even adapt our implementation to use existing translations directly? https://github.com/hustcc/timeago.js/blob/master/src/lang/he.ts
Your solution counts with the choice that every language can have its own specific strings for the plural forms, kind of like how it is established with the PO format, if properly set up. Right now, there's no such feature in RA's localization system: every language only has access to the same strings, which are exported to Crowdin. It simply takes and gives whatever is in the US English file.
Alright, I'm back among the living.
Isn't 'approximate time since' kinda too technical? Like 'Ago' seems to just roll better off the tongue and is less obfuscatory in language.
Well, this is just a suggestion, so if you prefer the old term then that's how it'll stay.
why not both instead of replacing it
I mean, it's possible, I guess, though personally I'm not in love with this idea.
And surely the problematic languages can be dealt with somehow
Code-wise? Sure. The problem is the translation bit - the way localisation works in RA is not conductive to this and I don't think Crowdin supports this sort of thing either.
Like simply making the option unavailable if the translation is impossible
IMO this is the worst course of action and should be avoided. I'd rather have the feature be always in English than to just not offer it when people use their preferred language - I just don't see a reason to put features (especially mostly numeric ones) behind an artificial 'language barrier'.
This is an issue that's been faced and tackled by a number of software projects before us, such as this one: https://timeago.org/. Is there a reason we can't solve it similarly?
Well, yes, that reason being: we would need to pretty much re-design the way localisation is handled. Which is, obviously, an enormous endeavour to undertake.
we could always avoid singulars altogether
That doesn't really improve anything for languages which have more than one plural form (like Russian and Arabic), which are the main concern here.
In conclusion, I can see that the unit approach is not liked - a bummer to me, but what can ya do. Since this whole plurals fiasco is not taken into consideration literally anywhere else in this app, I suppose our users (and translators) will have to deal with somewhat broken language in RA's menus for the time being.
I'll refactor this PR to only fix the broken. up. fixed. position. sentences. This, I refuse to accept. As for the plurals conundrum, I guess I'll open an issue for it, maybe a solution can be implemented in the future.
why not both instead of replacing it
I mean, it's possible, I guess, though personally I'm not in love with this idea.
Just that since there are multiple options for exact time formats (which are not locked to the language/region), there could also be more than one string approximation, such as different word orders tailored for certain needs, and forced to certain unit etc.
Besides renaming the PR as its target was change, was there anything else left to do here?