@Toby To continue the discussion from Gitter...
The idea was that the JS front-end would receive the translations with the forum. or lib. prefix stripped.
Okay, so I was understanding you correctly the first time. ?
I thought this might be a good thing to do since translations outside of the forum/lib scopes aren't available to the front-end anyway – so why bother referencing the scope explicitly?
Primarily because the translation could be under either forum or lib, so we need that information to tell us where to look for it. If all the translations for the front end were together under forum then sure, there'd be no need to include the scope in the code.
There are two problems with this idea, as you've pointed out:
If a translation is defined in both the lib and forum scopes (eg. lib.hello_world and forum.hello_world), then the forum one will override the lib one.
However, maybe this is actually desirable! The use-case is a bit contrived, but if one of the lib/*.js functions references lib.hello_world for example, then you want to use a different translation for that in the forum front-end but not the admin front-end, you can. It just requires a slight shift in the way you think about the lib, forum, and admin scopes – they are all really the same scope, just with different availabilities depending on which front-end is being used.
Yes, this would be quite a shift in the way we think about these prefixes. Up until now, I've been thinking of them as distinctive; that is, I've been assuming that the info we're calling "scope" is sufficient to distinguish one translation from another. (See my response to the first quote, above.)
There may never be any need to create a forum variant of a lib translation (so any use case is bound to be very farfetched, as you say), but it would be an interesting little trick to leave open for someone who wants to exploit it. And given that lib is just a pool of translations that may be used in either UI (forum or admin), it does make some sense to omit that information in the code, as you say.
- It could be confusing to have defined the translations within their scopes in the YAML file, but then to access them without that scope (only on the front-end). However, I think if we document it clearly it shouldn't be a problem.
It will certainly take a bit of work to explain this so devs and localizers will be able to wrap their minds around it easily. But I think that's a hurdle we can overcome without too much fuss.
The real problem lies in practicality. Up till now, since we've been treating the scope as distinctive and alphabetizing the keys within each scope, it's been fairly easy to be certain that we're not accidentally creating a duplicate key.
When we omit the scope from the code, however, it opens up the possibility that a dev might accidentally create a key in forum or admin that duplicates a key in lib. While such duplication might be desirable in some farfetched use cases, as you say, the potential for doing this unknowingly could make troubleshooting a bit harder. Basically, every key added to forum or admin will need to be checked against lib, and every key added to lib should be checked against both forum and admin, to avoid conflicts.
I don't think we've created any such conflicts yet. (A key reference in one of the lib translations would be a clear hint that we had done so!) And the lib section is small enough that we may not need to worry about it too much. But it is not inconceivable that this could cause someone unnecessary bother down the road.
Nonetheless, it might be worth doing. Let me make sure I'm understanding this correctly:
Using keys in code:
- The scope should be omitted when using keys in files in the
forum and admin directories.
- The scope should be explicit when using keys in files in the
lib directory. Or can we omit it here too?
- How about
views and email and api? All explicit?
How the compiler works:
- When compiling for the admin page, it combines
admin and lib translations (admin has right of way).
- When compiling for the forum page, it combines
forum and lib translations (forum has right of way).
Basically, we only have to be concerned about overlap between lib and either admin or forum. There's no chance, for example, that a forum translation could conflict with an admin translation. Have I got that right?
