Suggestion #26929
Inline translation
| Status: | New | Start date: | 2011-05-20 | |
|---|---|---|---|---|
| Priority: | Could have | Due date: | ||
| Assigned To: | - | % Done: | 0% |
|
| Category: | - | |||
| Target version: | - | |||
| Has patch: | Tags: |
Description
Hi folks,
in usual project context, labels and strings in templates neither can be really re-used nor an abstract, generic "variable name" for each string can be found.
So I would suggest some kind of "inline translation" View Helper, it uses an appoach I used to have use of in earlier "pibase"-projects.
It would read simply the following:
{f:inlineTranslate(values:{def:'My translation',de:'Meine Übersetzung',fr:'Mon translation(?)'})}
This would reduce update overhead because translations that are anyway only used once in a specific context do not have to be updated in two files (the template file where the key is used and the locallang-xml-file).
Consider the situation where the customer wants to change the intro text of the login screen from "Please login using your credentials" to "Please login using your user name and password".
With "the old style" you have to look at the template file, obtain the key, switch to the locallang file and correct it in each language. And maybe the change of the textual value should result in changing the key also; changing the key could result in conflicts with existing ones...
What do you think?
I just wrote a project specific view helper that could be ported; I would be honoured to find it in the core.
History
#1 Updated by Christian Zenker about 4 years ago
Hi.
Although I like the simplicity of the viewHelper, I would not want it to be placed inside the core. Locallang.xml is there for a good reason: Making translation simple. By having all labels inside that file, you can easily translate your plugin to a different language by translating all the labels in that file – done. With your VH, you'll have untranslated strings inside the templates remaining, making locallang.xml almost useless.
Additionally I think that using this simplified VH, might cause you trouble later on. If your customer has already requested 3 languages, how can you be sure he would not want to have a forth in a few months? In this case locallang.xml would be much quicker to translate.
So in conclusion I would say, that the simplicity of this VH does not make up for the disadvantages in general.
#2 Updated by Bastian Waidelich about 4 years ago
- Tracker changed from Feature to Suggestion