TYPO3 Core

I do not think it is a good solution to put this into pi_getLL.
Create an extra method e.g. $expandedKey = pi_expandKey('salutation'); for expanding the key, containing these lines. This is because it will be needed only for very few keys with which pi_getLL is called. Salutation should be a parameter of it.

---------
// If the suffix is allowed and
// we have a localized string for the desired salutation, we'll take that.
if (isset($this->conf['salutation']) && in_array($this->conf['salutation'], $this->allowedSuffixes, 1)) {
$expandedKey = $key.'_'.$this->conf['salutation'];

if (isset($this->LOCAL_LANG[$this->LLkey][$expandedKey])) {
    $key = $expandedKey;
    }
}
--------------

I think the caller should not have to care about expanding the key or knowing if a salutation applies or not.

Perhaps, the key expansion could be set by pi_loadLL ?

if (isset($this->conf['salutation']) && in_array($this->conf['salutation'], $this->allowedSuffixes, 1)) {
$this->LLSalutation = '_'.$this->conf['salutation'];
}

So that we would have in pi_getLL, something like:

if (isset($this->LOCAL_LANG[$this->LLkey][key.$this->LLSalutation])) {
$key = key.$this->LLSalutation;
}

Hi,
there needs to be a fallback as well - if the locallang-key doesn't exist.
Greets, Sebastian

The original code in the salutation switcher does exactly that. It looks like this:

class tx_salutationswitcher extends tslib_pibase {
/** list of allowed suffixes */
var $allowedSuffixes = array('formal', 'informal');

/**
 * Returns the localized label of the LOCAL_LANG key, $key
 * In $this->conf['salutation'], a suffix to the key may be set (which may be either 'formal' or 'informal').
 * If a corresponding key exists, the formal/informal localized string is used instead.
 * If the key doesn't exist, we just use the normal string.
 *
 * Example: key = 'greeting', suffix = 'informal'. If the key 'greeting_informal' exists, that string is used.
 * If it doesn't exist, we'll try to use the string with the key 'greeting'.
 *
 * Notice that for debugging purposes prefixes for the output values can be set with the internal vars ->LLtestPrefixAlt and ->LLtestPrefix
 *
 * @param    string        The key from the LOCAL_LANG array for which to return the value.
 * @param    string        Alternative string to return IF no value is found set for the key, neither for the local language nor the default.
 * @param    boolean        If true, the output label is passed through htmlspecialchars()
 * @return    string        The value from LOCAL_LANG.
     */
    function pi_getLL($key, $alt = '', $hsc = FALSE) {
        // If the suffix is allowed and
        // we have a localized string for the desired salutation, we'll take that.
        if (isset($this->conf['salutation']) && in_array($this->conf['salutation'], $this->allowedSuffixes, 1)) {
            $expandedKey = $key.'_'.$this->conf['salutation'];

if (isset($this->LOCAL_LANG[$this->LLkey][$expandedKey])) {
                $key = $expandedKey;
            }
        }

return parent::pi_getLL($key, $alt, $hsc);
    }
}

I don't see why this suffix stuff needs a) a well-know configuration and b) needs such a complex setup with allowed suffices.

Simply extend getLL with a suffix parameter. Any will do, I see little point in checking for allowed vaues. Either the string resource exists or it doesn't

If you really want a TS config setting, then DO NOT name it saluation. Call it something like LLswitch or something that tells what it does. Not what was yur first idea how to use it was.

And Stanislas, i do think the caller should know what he wants. So I dislike the TS config setting.

Martin, what do you mean by "a well-know configuration"? Please shed some light on this.

The advantage of this way of doing the switching (with an optional TS config) is that it is completely transparent: An extension that uses the switcher can keep all calls to pi_getLL() unchanged. If you add another parameter, all call would need to get changed, which would waste developer's work time. Make it easy for the developers while keeping compatibilty. :-)

The thing with the allowed suffixes is just error-checking from my extension. It doesn't neccessarily need to be there.

Currently, switching salutation modes is the only way this feature is used. Unless someone intends to use this feature in other ways, I propose keeping that name so that the purpose of the variable is clear to the user who sets it during configuring an extension. (It's the user to whom the name should be meaningful, the internals of development are secondary to that.)

Apart from that, I don't think that abbreviations like "LL" facilitate understanding the purpose of a variable. Make it as clear as possible, not cryptic or extra-geeky.

With "well-known" I mean a config variable that is shared by (almost) all plugins.

"LLswitch" or "LLmodifier" is more transparent to the admin because he will use it like this:

plugin.tx.foobar_pi1 {
LLmodifier = informal
_LOCAL_LANG.de {
salutation_informal = Hallo
}
}

BTW, "LLmodifier" ("salutation") should be a stdWrap.

Sebastian and Franz, just on case you want to make a patch. I really object to "salutation" (-1 on the name choice).

plugin.tx.foobar_pi1 {
LLmodifier = informal
_LOCAL_LANG.de {
salutation_informal = Hallo
}
}

This is fine with me (maybe LLsuffix would be more precise).

However, I would really like pi_getLL to chek for the presence of the suffix in the TS config, check for the presence of the suffixed label in the current language and return it if available, and otherwise fallback to normal processing. It think this is important because this would allow to make the feature immediately available for all plugins wihout any change to the code of the extensions.

The patch implements support for plugin.foobar._LOCAL_LANG_suffix in pi_getLL.

I think this is not sufficient. More than one suffix will be needed soon.

Franz, you can set any suffix you want. The point is to set the TS config prior to calling pi_getLL. my patch is in this regard exactly the same as the original salutationswitcher.

I could make _LOCAL_LANG_suffix a stdWrap, so you can have more than one suffix with a single TS setting (think registers).

I could also add an extra argument to pi_getLL that sets the suffix directly from the pluigin (PHP).

So you have multiple suffices from TS for the admin and a manual override for the pluign developer.

Hello Martin,
this is fine. However I want to use several suffixes and I do not want to fill in everything in the language file. So it shall look starting with the first suffix until to the last. It shall display the first text it will find. This makes it possible to use several salutation and text kinds, e.g. funny, happy or sad ones. And it would take the next suffixed text found in the language file or TypoScript.

What are the points against the file that I have provided (some changes made to Martin's file)?