chore(i18n): Introduce Locale, Message, and MessageBundle

[ewinslow]

These concepts will help us clean up the i18n code significantly.

TODO:

• Pull the locale mapping into MessageBundle so that it is essentially Map<Locale, Map<string, Message>>
• Add a __toString handler on Message that outputs the template. This would allow us to avoid calling "format" with no arguments, making views a wee bit more terse: I.e., {$message} instead of {$message->format()}
• Rename Message to MessageTemplate
• Make template protected instead of private
• Replace isset checks with plain boolean checks where possible
• Add support for translation_key_exists

[ewinslow]

This test should give some idea of how I envision this all working together.

Eventually we will move most of the logic for loading the translation resources into a FilesystemMessageBundle class.

[juho-jaakkola]

The approach LGTM

[ewinslow]

This should be ready for a final review before I pull it in. But if I don't hear back soon I'll just pull it in anyways as it is a private refactor that only adds classes/tests and doesn't change any runtime configuration/logic at all yet, plus I've already got an LGTM on the direction.

[mrclay]

Shouldn't this be a Template or MessageTemplate?

[ewinslow]

Yes, message template would be clearer.

[mrclay]

My only concern here is how many objects we'd create/destroy translating a single page. Each translation constructs a new "en" Locale (that's easily optimized) but also a new SprintfMessage.

[ewinslow]

This definitely assumes object creation is cheap, and is designed this way to allow mixing sprintf templates with ICU templates. We could optimize in 2.0 by removing the message objects entirely since we will only want to support ICU.

[ewinslow]

But at the end of the day there is definitely the possibility of adding a few ms power request because of this change...

[jdalsem]

There are some recent additions made to the translation class (like translation_key_exists). Those features are not yet added to these classes. Will you add those later?

[ewinslow]

I need to update this PR with those improvements.

[ewinslow]

So the MessageBundle I think accomplishes what translation_key_exists wants, because you get just check if the return value of get is null. to see whether the key exists. No warnings are logged for trying to get a null value. Those are/should-be done at the translator level.

[juho-jaakkola]

So this doesn't need anything else but a final review?

[ewinslow]

That is correct

[ewinslow]

Just posted several updates addressing all outstanding comments/todos, so PTAL and I will pull in after a couple LGTMs.

Main thing to note here is that we are just introducing the classes, not even using them yet.

[juho-jaakkola]

LGTM