On 12/12/2015 02:54 AM, Georg Baum wrote:
> Guillaume Munch wrote:
>
>> Le 06/12/2015 18:18, Guillaume Munch a écrit :
>>> Le 05/12/2015 21:41, Scott Kostyshak a écrit :
>>>> On Tue, Dec 01, 2015 at 08:26:35PM +0000, Guillaume Munch wrote:
>>>>> is it
>>>>> possible to implement the format change (which I feel is stable now)
>>>>> for 2.2.0 and implement the polished visible changes in 2.2.1 or 2.2.2?
>>>> I am fine with this but I'd like to get a +1 from someone else. Have we
>>>> done this in the past? It seems like a great strategy to me.
>>>>
>>> Ok, since everyone agrees that this is a good idea, let's just do the
>>> format change for now.
>>
>> Here is the patch with the format changes.
>>
>> The second argument of OutlinerName is a translatable string. To do
>> this, I adapted lyx_pot.py and I load the translations using
>> translateIfPossible(). Is this correct?
> I would not store the translated result in TextClass. This makes it too easy
> to use it incorrectly, for example if something is displayed in the work
> area it should be translated using the buffer language. In general
> translateIfPossible() is the correct funtion to use, but I'd call it when
> the outliner data is collected.
I'll guess that there may also be a need at some point to compare this
string to some other one, and we don't want to compare translated
strings. We also might want to use it for output purposes, e.g., in
plaintext or XHTML, and then we might need a different translation, or
none. So I agree with Georg: Just store the raw string here, and
translate it when a translation is needed.
>
>> + case LT_ADDTOTOC:
>> + lex >> toc_type_;
>> + if (toc_type_ != "0" && toc_type_ != "false")
>> + add_to_toc_ = true;
>> + break;
> This looks fragile. If you want to make it possible to switch off
> add_to_toc_ even if it has been set before, then the else branch is missing.
> If you do not want to make this possible, then I don't see the need for this
> special treatment and would always set add_to_toc_ to true. If somebody does
> not want to have a toc entry then he simply should not write a toc type in
> his layout. The special code is mixing namespaces btw, it would not be
> possible to create a to type "false".
We do need something like this. It should be possible to include some
layout code that activates a TOC for some inset, and then later override
that. But it is probably better to use an empty string, as we do
elsewhere. So then we could have:
add_to_toc_ = !toc_type_.empty();
Richard
