Marking messages that don't need to be translated

Pontoon
#1

Would there be a way to signal to Pontoon that a message doesn’t need to be translated? (examples below use .ftl format)

Something like this:

-shared-msg = Reusable term # requires translation

some-public-message = { -shared-msg } # OK (no need for translation)
another-pbulic-message = This can be translated { -shared-msg } # requires translation

Where the OK comment would signal pontoon that some-public-message doesn’t need to be translated directly and would mark it as already translated?

I saw something that hinted this behaviour on this legacy format, but I’m not sure this would work with fluent as well?

Use case:
I have an API endpoint rendering .ftl files with an aggregation of all products in a shop.
Some products have the same title or same description, so, in order to make sure those a e only translated once (where needed), I am creating terms that are reused across many of those messages like:

-product-name--548507ae = Four credit card case

product-925-03-name = { -product-name--548507ae }
product-925-03-color = Red
...
product-3020-95-name = { -product-name--548507ae }
product-3020-95-color = Yellow

So as you can see product-925-03-name and other products with the same name don’t ever need to be translated individually, but rather, only the term it references.

Also, it may be important to mention that the API endpoint generates about 1500 messages, of which, only ~300 need translation and are not duplicates (are not just term references), so, marking these remaining 1200 words as OK would really help to keep the localization easier to maintain.

Thank you in advance

#2

There is no way to tell Pontoon not to translate strings, in any format. You can “pretranslate” that content in the repository, and Pontoon will pick it up as already translated, since sync is bidirectional.

The .lang example is unrelated: you need the { ok } to tell the system that your string is translated, and happens to be identical to English. That’s a shortcoming of using the source string as the ID. And you should stay away from that format, really :wink:

As for general approach, I’d argue that this is not a good use of Fluent terms. Four credit card could be a standard message, and then the code would use that message where needed (directly, since they’re not terms). The mapping withing product code and label would live in the code.

1 Like
#3

Thank you for this. That makes sense.

I will try hashing messages such as four credit card, and using that as a way to get the reference back on the client.

So, in this case perhaps the CRC32 hash could work with product-name-2a647c36 = four credit card and make sure to also hash on the client site in order to get the path. This requires me to have a fallback value already in place, though. Otherwise, it wouldn’t be possible to find out the path to the message, I think. Another downside is that the context won’t be very clear to the translator, as it’s a hash.

At least this way I could guarantee that the message is being generated only once per translation required.

Thanks again for following up so quickly and for the insightful suggestion!

#4

I should start with noting that we also have a Fluent category on this discourse instance, and your question is actually more about Fluent than about Pontoon.

One thing I notice, and I notice you may not have control over it, is the lack of structure around products and their variants. If you actually have a product identifier, I’d suggest to use that to look up product names.

Another thing I notice is colors. IIRC, different cultures and as such languages categorize shades of colors differently. I.e., something that’s a shade of blue in one language might be a shade of green or red in another.

As for the use of terms, I’d suggest to only use terms if you’re also using them as part of generic phrases. Then term variants and attributes become relevant.

If you’re expecting partial translations on your production system, you want to read this post: On Message- and Termreferences.

Last but not least, if you have messages that you don’t want to expose to l10n in general, you can put them into a generic FTL file, and add the same resource to all bundles you use.

1 Like
#5

That is a great discussion on the topic. Thanks so much for referencing this, as it will help be to better plan how localization will be used on this project.

Bear with me while I learn how to post things around. :slight_smile: — It’s great to know that there’s also a Fluent category. I vastly appreciate you guys taking the time to help and educate.

Cheers!

1 Like