Timers don't support localized input (Missing text labels)

[savissimo]

I've noticed some text labels are not translated. For instance, if I insert a timer with ~{19%minuti} and another one with ~{4%ore}, this is what I get:

The timer in hours (4 ore) is ignored for the total time if it's written in Italian, while it's counted if I write ~{4%hours}, which doesn't happen with minuti/minutes - but this is probably out of the scope of this fork - I'm not sure about this.

However, what I wanted to point out is that the timers list uses the values verbatim, but the total time uses its own "hours" and "minutes" labels. Can we translate those ones too? I'll take a look into that if I manage to, but maybe you already know where to look.

[seeyouspacecorgi]

I've missed a couple of strings in the timers, thanks for pointing it out!

I've found the issue with ~{4%ore} not working, as you suspected it doesn't come from cooklang-obsidian but from the parser: cooklang-js, specifically this function.
From what I understand, it parses any unit starting with the letter 'h' as hours, 'm' as minutes and 's' as seconds. Hence why ~{4%heures} does work and ~{4%Stunden} becomes a 4 seconds timer.

The simplest solution would be to edit the parser, but as it returns units anyway I think a workaround is possible. Maybe using moment.js ? As such a workaround would mean rewritting the function (and probably a good chunk of the timers), I'm leaving the units untranslated for now.

If you'd like to take a look at the issue, here's a starting point.

[savissimo]

~{4%Stunden} becomes a 4 seconds timer

Lol, this is even worse 😄

[savissimo]

I've found the issue with ~{4%ore} not working, as you suspected it doesn't come from cooklang-obsidian but from the parser: cooklang-js, specifically this function. From what I understand, it parses any unit starting with the letter 'h' as hours, 'm' as minutes and 's' as seconds. Hence why ~{4%heures} does work and ~{4%Stunden} becomes a 4 seconds timer.

So this is definitely out of scope here, as I suspected.

The simplest solution would be to edit the parser, but as it returns units anyway I think a workaround is possible. Maybe using moment.js ? As such a workaround would mean rewritting the function (and probably a good chunk of the timers), I'm leaving the units untranslated for now.

If you'd like to take a look at the issue, here's a starting point.

I haven't looked at the code any farther than that file, but I'm not sure I get what you mean. The strings to localize are there to grab - or is it somewhere in the flow where it's not easy to use i18n()?

[seeyouspacecorgi]

I haven't looked at the code any farther than that file, but I'm not sure I get what you mean. The strings to localize are there to grab - or is it somewhere in the flow where it's not easy to use i18n()?

Flow could be an issue (I'll have to look into that), but it could be easily be solved with something like formatted-duration: {{hours}} {{minutes}} {{seconds}} in each translation file.

However I believe there are more elegant solutions to localize durations. In the code, all timers functions rely on Timer.seconds (which currently gives incorrect values). The workaround I was thinking of would use Timer.amount to create a date/time object with either plain js or moment.js, then use the built-in functions to output a formatted and localized duration.

In short, if the parser isn't updated to support localized input, this plugin timers need to be, so I'm not going to localize the output just yet. Does this make more sense ?

[savissimo]

Yes, now it's clear. I've posted an issue about localizing the parser, we'll see what happens.

[seeyouspacecorgi]

I've created a branch to try to solve the issue. Converting localized time units to seconds seems to work, ~{1%Stunde}, ~{1%ora}, ~{1%uur} all become one hour timers, but this needs more tests (ideally with non-latin based languages too).

Units have their own file, to make it easy to grab in case deathau wants to update the parser. That might also help to localize ingredient quantities for additions and/or conversions if it becomes a feature.