[FLOW3-general] FLOW3 I18n

[Ferdinand Kuhl]

Hi Zach,

I do think the inpossibility to use language-files from different packages 
is not optimial either.

If you only need translations for your single application, you can help 
yourself with a quick workaround using the object-configuration framework:

Just create a "Objects.yaml" in your Configuration directory and put the 
following lines there:

TYPO3\FLOW3\I18n\TranslationProvider\XliffTranslationProvider:
  properties:
    xliffBasePath: { value: 
"resource://DigiComp.Fairdrive/Private/Locale/Translations/" }

(Indentation might get lost in this email)

Greetings,
Ferdinand


Zach Davis wrote:

> So, I've been digging into Karol's I18n implementation in FLOW3 (nice
> work!) in an effort to localize some labels in my application, and have
> hit a roadblock.  The issue that's slowing me down has been identified
> here:
> 
> http://forge.typo3.org/issues/14037
> 
> In a nutshell, a hard-coded path in the code means that all this I18n
> work isn't really usable yet, since xliff files have to be stored within
> the FLOW3 package. I'd like to at least try to contribute a patch to fix
> this, but am not sure that I know the best way to solve the problem.
> 
> In my case, I need to access some translated labels in a controller so
> they can be assigned to a view, as well as in the view, which can be
> done via a view helper. One way to solve this problem would be to just
> remove the base path altogether and make calls to getTranslationById and
> getTranslationByOriginalLabel provide a full path to the xliff resource.
> 
> 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?
> 
> Zach