Am 12/22/2012 07:41 PM, schrieb janI:
I have nothing a little extra work, if I other for much more work...no
problem.
I tested your idea, and it works with one big exception:
some of the are used for control commands:
...
and I do not think it is a good idea to change that.
But until now,
I have nothing a little extra work, if I other for much more work...no
problem.
I tested your idea, and it works with one big exception:
some of the are used for control commands:
...
and I do not think it is a good idea to change that.
But until now, I have only found 2 places where <> is
Am 12/22/2012 12:35 PM, schrieb janI:
I like you idea !!! much easier to handle, the implementation might be a
little more complicated, because I have to poke around in the code to see
where the variables are used.
Yes, the initial work is maybe a bit more than wanted. However, the
communicati
I like you idea !!! much easier to handle, the implementation might be a
little more complicated, because I have to poke around in the code to see
where the variables are used.
thanks for the idea.
Jan I.
On 22 December 2012 12:31, Marcus (OOo) wrote:
> Am 12/21/2012 11:00 PM, schrieb janI:
>
>
Am 12/21/2012 11:00 PM, schrieb janI:
For general information, I have added a new bug 121536, regarding problems
with translations.
The content of the msg text in the source code is non translatable due to
ambiguity.
[xxx] means normally a variable will be inserted here
example: "[Time]" may NO
For general information, I have added a new bug 121536, regarding problems
with translations.
The content of the msg text in the source code is non translatable due to
ambiguity.
[xxx] means normally a variable will be inserted here
example: "[Time]" may NOT be translated but "[l]" (for load) sho