On 11/03/2012 08:40 AM, Eduard Moraru wrote:
> Additionally, the $msg tool will have the same behavior as the new
> {{translation}} macro, right? Meaning that the existing velocity code will
> continue to use the $msg tool and the new translation macro will only be
> used more in pure wiki syntax where users will not be forced to use
> velocity to have translated keys. So for the rest of the heavy code where
> translations are used a lot, $msg is still short as before.
>
> Is this correct?
Not quite, $msg is supposed to be replaced by $services.localization.
But $msg will still be available for backwards compatibility for a while.
> Thanks,
> Eduard
>
> On Fri, Nov 2, 2012 at 8:46 PM, Sergiu Dumitriu <[email protected]> wrote:
>
>> On Fri, Nov 2, 2012 at 7:13 AM, Thomas Mortagne
>> <[email protected]>wrote:
>>
>>> Hi devs,
>>>
>>> Quick vote for the macro name:
>>> * {{l10n}}
>>> * {{locallization}}
>>>
>>> localization is a bit too long for a macro so I would go for "l10n".
>>>
>>> We can also decide to maintain both aliases.
>>>
>>>
>> Localization is a process, it involves the whole product, so it's not
>> appropriate to use it on just one string.
>>
>> I think that translation or translate is the right term.
>>
>> And I think that a noun is better, for consistency. We're describing what's
>> inside the macro (or what comes out of it), not what the macro does:
>> messageSender, column, chart, livetable...
>>
>> -1 for abbreviations, even though this one will be used more often than the
>> other macros, it's always a good idea to stay away from very short names.
>> We wouldn't use abbreviations in our Java API method names, would we?
>>
>> So, +1 for {{translation}}.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
