I’d like to spend a bit more time on this hypothesis. I think there are two kinds of partial localizations:
- partial by mistake or neglect, when the target localization has errors or is otherwise temporarily incomplete,
- partial by design, when the target localization extends the base one.
I consider partial by mistake to be error scenarios and I don’t see the need to design the entire architecture and the API around them.
On the other hand, I consider partial by design to be a big feature, not entirely new but also one that we haven’t explicitly prioritized before. As such, I think it’s reasonable to scope it with some limitations, by bounding it by (to be discussed) requirements. In other words, I’d like to be able to state that in order to use Fluent to do partial-by-design localization, one needs to meet some additional requirements.
I’d like to spend a bit more time thinking about whether the same rules should apply to message references and term references. Each term has an API which may only be good in the language the term has been originally defined in. A term’s API may change, and the other (partial) localization referencing it would still expect the old API. It might be that terms should only ever be resolved just within the bundle of the message referencing them.
These could be solved by bounding the feature with requirements: term references would only be resolved within the same bundle, and message references could be forbidden from function arguments.
And then the iterable approach could actually be a viable one.
Message references keep encouraging bad practices, like excessive factorization in the spirit of DRY. This creates more work for the reviewers and localizers. The same goals can be achieved via CAT tools, with the benefit of allowing more customization and expression. Deprecating message references from the syntax could be a good move long term, which I’d like to keep on the table for now.