Georg Baum wrote:
Abdelrazak Younes wrote:
My idea would be to cache the translated text instead of translating
each time updateLabels() is called. But I am not sure I can do that on
untranslatable layouts.
They are not different than the translatable ones. The only problem I can
Georg Baum wrote:
Abdelrazak Younes wrote:
My idea would be to cache the translated text instead of translating
each time updateLabels() is called. But I am not sure I can do that on
untranslatable layouts.
They are not different than the translatable ones. The only problem I can
[EMAIL PROTECTED] writes:
| On Fri, 12 Jan 2007, Georg Baum wrote:
|
| Abdelrazak Younes wrote:
|
| Georg Baum wrote:
| They are not different than the translatable ones. The only problem I can
| imagine is that the cache could get out of date if somebody changes the
| layout file.
|
|
[EMAIL PROTECTED] writes:
| On Fri, 12 Jan 2007, Georg Baum wrote:
|
| > Abdelrazak Younes wrote:
| >
| >> Georg Baum wrote:
| >>> They are not different than the translatable ones. The only problem I can
| >>> imagine is that the cache could get out of date if somebody changes the
| >>> layout
Hello,
I finally know what is causing the slowness in updateLabel() on Windows!
The culprit is the translation done in Buffer::translateLabel():
docstring const Buffer::translateLabel(docstring const label) const
{
if (support::isAscii(label))
// Probably standard
Abdelrazak Younes wrote:
My idea would be to cache the translated text instead of translating
each time updateLabels() is called. But I am not sure I can do that on
untranslatable layouts.
They are not different than the translatable ones. The only problem I can
imagine is that the cache
Georg Baum wrote:
Abdelrazak Younes wrote:
I seem to remember from previous discussions that user-defined layout
command are not allowed any more.
Wrong. That would mean that nobody could create custom layouts in
~/.lib/layouts. There is no reason to forbid that.
Now I see that I overread
Georg Baum wrote:
Georg Baum wrote:
Abdelrazak Younes wrote:
I seem to remember from previous discussions that user-defined layout
command are not allowed any more.
Wrong. That would mean that nobody could create custom layouts in
~/.lib/layouts. There is no reason to forbid that.
Now I
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdelrazak My idea would be to cache the translated text instead of
Abdelrazak translating each time updateLabels() is called. But I am
Abdelrazak not sure I can do that on untranslatable layouts.
This is a problem with multiple
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdelrazak Yes, that's what I meant. The problem is that I don't know
Abdelrazak what's there to translate. In a koma-script or article
Abdelrazak layout, here is what
layout- labelstring() gives inside 'expandLabel()':
Abdelrazak raw
Jean-Marc Lasgouttes wrote:
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdelrazak Yes, that's what I meant. The problem is that I don't know
Abdelrazak what's there to translate. In a koma-script or article
Abdelrazak layout, here is what
layout- labelstring() gives inside
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
Abdelrazak == Abdelrazak Younes
[EMAIL PROTECTED] writes:
Abdelrazak My idea would be to cache the translated text instead of
Abdelrazak translating each time updateLabels() is called. But I am
Abdelrazak not sure
Georg Baum wrote:
Abdelrazak Younes wrote:
My idea would be to cache the translated text instead of translating
each time updateLabels() is called. But I am not sure I can do that on
untranslatable layouts.
They are not different than the translatable ones. The only problem I can
imagine is
Abdelrazak Younes wrote:
This last line in particular looks suspicious. Why do we set environment
variable at each translation request?
Because the environment variable determines what language gettext will use,
and we don't know what other message was translated before. To my knowledge
no
Abdelrazak Younes wrote:
Georg Baum wrote:
They are not different than the translatable ones. The only problem I can
imagine is that the cache could get out of date if somebody changes the
layout file.
Do you mean in the Document settings? If yes, then we just need to reset
the cache when
Georg Baum wrote:
Abdelrazak Younes wrote:
This last line in particular looks suspicious. Why do we set environment
variable at each translation request?
Because the environment variable determines what language gettext will use,
and we don't know what other message was translated before. To
Abdelrazak Younes wrote:
Georg Baum wrote:
Abdelrazak Younes wrote:
This last line in particular looks suspicious. Why do we set environment
variable at each translation request?
Because the environment variable determines what language gettext will
use,
and we don't know what other
On Fri, 12 Jan 2007, Georg Baum wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
They are not different than the translatable ones. The only problem I can
imagine is that the cache could get out of date if somebody changes the
layout file.
Do you mean in the Document settings? If yes,
Abdelrazak Younes wrote:
OK, thanks for the explanation. I am not pretending that I will solve
everything, don't be afraid ;-). We do have an internal in source
gettext. Couldn't we just support that and live all other version aside?
I'd rather like to get rid of that instead of completely
Hello,
I finally know what is causing the slowness in updateLabel() on Windows!
The culprit is the translation done in Buffer::translateLabel():
docstring const Buffer::translateLabel(docstring const & label) const
{
if (support::isAscii(label))
// Probably standard
Abdelrazak Younes wrote:
> My idea would be to cache the translated text instead of translating
> each time updateLabels() is called. But I am not sure I can do that on
> untranslatable layouts.
They are not different than the translatable ones. The only problem I can
imagine is that the cache
Georg Baum wrote:
> Abdelrazak Younes wrote:
>> I seem to remember from previous discussions that user-defined layout
>> command are not allowed any more.
>
> Wrong. That would mean that nobody could create custom layouts in
> ~/.lib/layouts. There is no reason to forbid that.
Now I see that I
Georg Baum wrote:
Georg Baum wrote:
Abdelrazak Younes wrote:
I seem to remember from previous discussions that user-defined layout
command are not allowed any more.
Wrong. That would mean that nobody could create custom layouts in
~/.lib/layouts. There is no reason to forbid that.
Now I
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> My idea would be to cache the translated text instead of
Abdelrazak> translating each time updateLabels() is called. But I am
Abdelrazak> not sure I can do that on untranslatable layouts.
This is a problem with
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Yes, that's what I meant. The problem is that I don't know
Abdelrazak> what's there to translate. In a koma-script or article
Abdelrazak> layout, here is what
layout-> labelstring() gives inside 'expandLabel()':
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Yes, that's what I meant. The problem is that I don't know
Abdelrazak> what's there to translate. In a koma-script or article
Abdelrazak> layout, here is what
layout-> labelstring() gives
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes
<[EMAIL PROTECTED]> writes:
Abdelrazak> My idea would be to cache the translated text instead of
Abdelrazak> translating each time updateLabels() is called. But I am
Abdelrazak>
Georg Baum wrote:
Abdelrazak Younes wrote:
My idea would be to cache the translated text instead of translating
each time updateLabels() is called. But I am not sure I can do that on
untranslatable layouts.
They are not different than the translatable ones. The only problem I can
imagine is
Abdelrazak Younes wrote:
> This last line in particular looks suspicious. Why do we set environment
> variable at each translation request?
Because the environment variable determines what language gettext will use,
and we don't know what other message was translated before. To my knowledge
no
Abdelrazak Younes wrote:
> Georg Baum wrote:
>> They are not different than the translatable ones. The only problem I can
>> imagine is that the cache could get out of date if somebody changes the
>> layout file.
>
> Do you mean in the Document settings? If yes, then we just need to reset
> the
Georg Baum wrote:
Abdelrazak Younes wrote:
This last line in particular looks suspicious. Why do we set environment
variable at each translation request?
Because the environment variable determines what language gettext will use,
and we don't know what other message was translated before. To
Abdelrazak Younes wrote:
Georg Baum wrote:
Abdelrazak Younes wrote:
This last line in particular looks suspicious. Why do we set environment
variable at each translation request?
Because the environment variable determines what language gettext will
use,
and we don't know what other
On Fri, 12 Jan 2007, Georg Baum wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
They are not different than the translatable ones. The only problem I can
imagine is that the cache could get out of date if somebody changes the
layout file.
Do you mean in the Document settings? If yes,
Abdelrazak Younes wrote:
> OK, thanks for the explanation. I am not pretending that I will solve
> everything, don't be afraid ;-). We do have an internal in source
> gettext. Couldn't we just support that and live all other version aside?
I'd rather like to get rid of that instead of completely
34 matches
Mail list logo
