Support for fluent terms not defined in the base language?

[Imberflur]

Describe the problem

Terms are similar to regular messages but they can only be used as references in other messages. Their identifiers start with a single dash - like in the example above: -brand-name. The runtime cannot retrieve terms directly.

https://projectfluent.org/fluent/guide/terms.html

Because terms are referenced by other messages it can be useful for translators to define terms that aren't present in the base language. We have a few languages that utilize this pattern and noticed a few issues when adopting Weblate:

1. No interface for translators to add novel terms for a particular language (afaict).
2. Since terms are treated like regular messages, the cleanup add-on will remove terms not present in the base language.

Describe the solution you'd like

I'm not familiar enough with Weblate to know how viable it is to address 1, but having an interface for this would be pretty useful.

For 2, it seems possible to add a check to not remove terms in the cleanup code. A more ideal solution would be to check if the term is referenced by any other message, but I assume that would be much harder to implement and it could removed terms that are just briefly unused.

Describe alternatives you've considered

A workaround for this is to manually add empty placeholder terms to the base language when translators need them (other than adding more friction, this also is just less discoverable, but perhaps we could include information about this in our project specific documentation for translators).

[nijel]

Presently, Weblate requires source language in monolingual translations to have all the strings. The reason behind this is that this is the only way you can define source string – the translation files do not have them.

[github-actions]

This issue has been automatically marked as stale because there wasn’t any recent activity.

It will be closed soon if no further action occurs.

Thank you for your contributions!

[juliancoffee]

Presently, Weblate requires source language in monolingual translations to have all the strings. The reason behind this is that this is the only way you can define source string – the translation files do not have them.

Can this limitation be lifted somehow? One of the solutions could be making a fake key with terms (for each language/component), where all terms will be listed as just string.

[nijel]

This would break several assumptions we currently have on translations, so it's hard to see what all would have to be changed.

[github-actions]

This issue has been put aside. It is currently unclear if it will ever be implemented as it seems to cover too narrow of a use case or doesn't seem to fit into Weblate.

Please try to clarify the use case or consider proposing something more generic to make it useful to more users.

[juliancoffee]

@nijel I thought about this more, and I'm increasingly leaning toward creating default entries for terms per component.

In general, Fluent may define messages in three ways.

# just key
some-key = Message
# attributes to key
some-key-with-attributes = Message
   .attr1 = First Attribute
   .attr2 = Second Attribute
# terms, private to the component, used mainly for guaranteed "syncing" of terminology, usually different per translation
-some-private-term = Weblate Inc
company-name = Provided by { -some-private-term }

Keys are still the only part of public API. Attributes can only be accessed with keys, terms cannot be accessed at all.
Currently, Weblate handles attributes as a plain string on the key.
I'm not sure why we can't create a dummy key for terms during serialization/deserialization so that Weblate better conforms to Fluent spec.

If there are some assumptions this would break, can you please share them?

[juliancoffee]

If that's an acceptable solution, I could try making an MR to translate-toolkit

[nijel]

Sorry, I don't know Fluent enough to decide this. @henry-torproject might be interested in discussing this (please let me know if I should stop bugging you with any Fluent related issues).

[henry-torproject]

Sorry, I don't know Fluent enough to decide this. @henry-torproject might be interested in discussing this (please let me know if I should stop bugging you with any Fluent related issues).

I still work with Fluent so I don't mind :)

@Imberflur why are your translators using Fluent Terms that are not being used in the original language? And would you expect to include Terms in the original (en-US?) language, that translators should not translate? I.e. why should some locales be using a Term that others should not?

In the Firefox context, the Terms are only used for brand and organisation names, so are always used in translations as well: https://searchfox.org/mozilla-central/search?q=%5E-.&path=.ftl&case=false&regexp=true. And I'm not aware of any deviations from this for all the other languages.

A more ideal solution would be to check if the term is referenced by any other message, but I assume that would be much harder to implement and it could removed terms that are just briefly unused.

The main problem with this is that the Term may be defined in one file and used in another, i.e. in another component or even outside of weblate. E.g. in Firefox, the "brand.ftl" file contains terms that are only used in many other .ftl files.