On 14/12/14 06:35, Khaled Hosny wrote:
total disregard to things that are intrinsic to the quality of any textual
material, let alone localisation.
Look at it this way.
There are 10,000 strings to translate.
At current rates, a professional translator will charge between
US$20,000 and
On 12/14/2014 11:07 AM, Sophie wrote:
...
And I have yet to see those technical marvels we've been promised will
compensate for this problem (promised with lot of eff-ing at silly
localisers, by the way).
Hey, those scripts are done by people to help us, so don't shout on
them. We will discuss
On 12/14/2014 11:59 AM, Rimas Kudelis wrote:
2014.12.14 02:43, jonathon wrote:
...
The more fundamental error is assuming that what is in source is
consistently en_US, or any other en_* variant.
It should be. You can look at it the other way around: anything that
gets in the source should
On 12/14/2014 12:47 PM, Khaled Hosny wrote:
I have been localising software for much longer
than I have been making fonts (or even writing
software) and I know that reviewing a few
hundred strings that were trivially changed is
not the end of the world. Usually the tool I'm
using (be it Pootle
Hi,
Do you agree that there is an error in the help for ERF.PRECISE function ?
In scalc/01.po arround line 38160
#. X74ZA
#: 04060115.xhp
msgctxt
04060115.xhp\n
par_id2963824\n
138\n
help.text
msgid ERF(LowerLimit; UpperLimit)
should be
...
msgid ERF.PRECISE(LowerLimit; UpperLimit)
How to fix
Hi
On 14/12/2014 06:59, Rimas Kudelis wrote:
It should be. You can look at it the other way around: anything that
gets in the source should consistently be en_US, not just
whatever_lingo_the_developer_had_in_mind.
Rimas
You're right and that is the way it has to be.
We face the issue that
