[FLOW3-general] FLOW3 I18n

[Sebastian Kurfürst]

Hey Zach,

> It seems to me that a better approach would be to have the translator
> class be aware of what package the current controller or view is in
> and figure out the resource bath path
> (PackageName/Resources/Private/Locale/Trasnslations) from that. There
> are lots of ways to do this, I suppose. The translator could be given
> access to the controller context or the request and figure it out that
> way. Or, I suppose the translator could be injected into the view
> and/or the controller and the context could be set on the translator
> when it's injected via a setter method. I tend to think that it would
> be nice to have a translator on hand in controllers, much like how the
> environment or the reflection service is present. Am I more or less on
> the right track here, or does anyone have any insight on how this
> issue might be resolved?
Best would be if the translation service gets a mandatory new argument
"Package Key", which is passed into getTranslationById() vs
getTranslationByOriginalLabel() -- as it must be possible to also get
labels from other packages.
Furthermore, as the Request is a prototype and there can be multiple of
them; but the translation service is a singleton, the translation
service should *not* store any reference to a Request, the current
package, ... -- it must appear stateless to the outside.

In Fluid VHs, we can fill the packageKey parameter by default; so that's
not an issue.

Then, we might still create a wrapper around the Localization Service
which could be available in every Controller and which is then aware of
the current request. However, I think it is important that the
translation service itself is *stateless* as we'll use it in a lot of
different scenarios lateron, like TYPO3 Plugins.

Looking forward to a patch :-) Would be cool if you could make the
translation service usable; as there is IMHO not much to do to reach
this state.

Greets,
Sebastian