Code convention: Should we avoid fetching a translation if it's not used?

[willbroderick]

I noticed two places where a translation is assigned, but potentially not used. Here and here.

Let's take one example:

assign title_default = 'labels.example_product' | t
assign title = product.title | default: title_default

In my own development patterns I tend to avoid using Liquid filters or assigning strings that aren't used.

Alternatives could be:

assign title = product.title | default: 'labels.example_product' | t

Or:

if product.title
  assign title = product.title
else
  assign title = 'labels.example_product' | t
endif

Which do others find most readable?

[bertiful]

Hey Will, thanks for kicking off this discussion 😃

There may be some consistency issues across the component files. However, we approached it this way due to some peculiarities with Liquid.

The code you provided for assign title = product.title | default: 'labels.example_product' | t doesn't work as you'd expect.

This is a value fallback pipeline, so in this case, the | t is applied to product.title and will throw an error if product.title returns a value. For example, imagine product.title returns A large hat, you'll actually get an error like Translation missing: en.A large hat, assuming that key name isn't defined in your locales file.

If product.title is falsy, it does not throw an error because it falls back to labels.example_product.

This is why in the first example with title_default, the translation is first assigned to that variable, and then that variable is used as the fallback only if product.title isn't defined.

Is your main concern that this may lead to a translation never being used, or more so the formatting of how we're actually outputting this logic in Liquid? Because in your last example, if product.title returns a value, the translation won't be assigned to title either.

[willbroderick]

You're welcome! And yes, my one-line example is embarrassingly wrong! Sorry about that.
I'll propose the if/else version.

Aside from that, it comes from not knowing the processing cost of 'a.b.c' | t
Perhaps it's an unrealistic example, but if 1000 of those are run on a page unnecessarily, could that noticeably increase TTFB? There is an assumption here that it would not.

[willbroderick]

I'm aware that this is fairly trivial. I just thought I'd mention it as it's something I'd flag in an in-house code review. Hope that's ok!