byteUnit in L20n

[Zibi Braniecki]

Hi all,

I'm trying to figure out how to solve in L20n a certain pattern in Gaia that currently requires pretty weird back-and-forth between JS and l10n code.

That pattern is units. Common code looks like this:

--------------------

# File sizes
byteUnit-B = B
byteUnit-KB = KB
byteUnit-MB = MB
byteUnit-GB = GB
byteUnit-TB = TB
byteUnit-PB = PB
byteUnit-EB = EB
byteUnit-ZB = ZB
byteUnit-YB = YB

fileSize = {{size}} {{unit}}

--------------------

And that requiers JS code like this:

document.l10n.formatValue('byteUnit-' + unit).then(unitString => {
document.l10n.setAttributes(element, 'fileSize', {
unit: unitString
});
});


---------------

Can we do this better in L20n? We can, but I'm not sure what pattern should we use and I think it's related to some things that Stas was wondering about some time ago.

1) One approach might be:

<byteUnit {
B: "B",
KB: "KB",
MB: "MB"
}>

<fileSize "{{$size}} {{byteUnit[$unit]}}">

-------------------

The problem with this approach is that it abuses hash values. Those are not *variants* of the same string, those are different strings. It would be pretty weird if a localizer decided to translate it as <bytUnit "B">, right?

Additionally, it's the only case scenario I can come up with that would validate the concept of a non-resolvable value. A Hash value without an index or default value.

Should we allow for that?

2) Another approach might be something like this:

<byteUnit
B: "B",
KB: "KB",
MB: "MB">


<fileSize "{{$size}} {{byteUnit::[$unit]}}">

But then again. Are those attributes of an entity?

3) Another option would be to keep each unit as a separate entity:

<byteUnit_b "B">
<byteUnit_kb "KB">
<byteUnit_mb "MB">

but then... how do I construct a placeable to reference unit that is a concatenated string ("byteUnit_" + $unit)?

I guess there may be more than those three approaches. Other ideas?

In the future, it would be awesome to have a macro/global that gives you the right unit size and integer for a given byte integer. Something where you pass "1025" and it returns "1" and "kb", but I don't think we'll get to macros anytime soon.

What do you think?
zb.

[Axel Hecht]

I think that all of these are hacks, and this one is a bit, too:

<unit($n) { $n < 1024 ? "B" :
"kB" }>
<value($n) { $n < 1024 ? $n :
$n/1024 }>
<betterNotify "{{ value($num) }} {{unit($num) }}">


This would work great, if we had number formatting, and if we had macros.

I think the double resolve is good until then, but please pass in the
fileSize as argument, so that we can pluralize octets.

Axel

[Staś Małolepszy]

I'm with Pike here: we need an imperative macro which understands values.
The hash semantics simply don't cut it here: we can't just fall back to
the default member because then we'd get the translation wrong (using the
wrong order of magnitude).

A good check to perform is to test if this would work well with
compare-locales. Hash members are private and I'd argue that using them to
store arbitrary data is wrong. If it's independent data, it should go into
separate entities, preferably public ones. Perhaps we should reconsider
the validity of hashes without index *and* default value in order to
discourage using them as data stores. Hash members should really be used
to store faceted data, like grammatical cases of the same datum.

* * *

(Now the crazy part.)

If macros turn out to be entities with some logic and the expressions are
simple decision trees, maybe we should consider merging them with hashes
where keys are predicates?

<unit[$n] {
$n < 1024: "B",
else: "kB"
}>

This still doesn't pass the compare-locale check, but now we have logic
which can help guarantee completeness.

-stas

On Mon, Aug 31, 2015 at 2:36 PM, Axel Hecht <l1...@mozilla.com> wrote:

> I think that all of these are hacks, and this one is a bit, too:
>
> <unit($n) { $n < 1024 ? "B" :
> "kB" }>
> <value($n) { $n < 1024 ? $n :
> $n/1024 }>
> <betterNotify "{{ value($num) }} {{unit($num) }}">
>
>
> This would work great, if we had number formatting, and if we had macros.
>
> I think the double resolve is good until then, but please pass in the
> fileSize as argument, so that we can pluralize octets.
>
> Axel
>
>
>
> On 8/31/15 7:08 AM, Zibi Braniecki wrote:
>

> _______________________________________________
> tools-l10n mailing list
> tools...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/tools-l10n
>