«

I've been looking for i18n for perl so that I can't get error messages
in Swedish. I haven't found anything, not _any_ other language.

Is there no such thing? Or have I just searched the wrong places or
for the wrong things?


--
MartinS

Am Wed, 02 Dec 2009 10:52:08 +0000 schrieb Martin Str|mberg:

> I've been looking for i18n for perl so that I can't get error messages
> in Swedish. I haven't found anything, not _any_ other language.
>
> Is there no such thing? Or have I just searched the wrong places or for
> the wrong things?

I haven't really thought about it, but do you think that this would
be a good thing?

The application should be localised, so the user can easily understand
the error message. But for the programming language itself, I find it
more important to be able to search the web
(or any other source) for the literal message to get further help.
Besides I would consider english nowadays as the lingua franca for
science and technology.

Sorry for not being really helpful.

Oliver

On 2 déc, 11:52, Martin Str|mberg <a...@sister.ludd.luth.se> wrote:
> I've been looking for i18n for perl so that I can't get error messages
> in Swedish. I haven't found anything, not _any_ other language.
>
> Is there no such thing? Or have I just searched the wrong places or
> for the wrong things?

Have you looked on CPAN ?

http://search.cpan.org/~audreyt/i18n-0.10/lib/i18n.pm

-- Klaus

Ben Morrow <> wrote:

> Quoth Martin Str|mberg <>:
>> I've been looking for i18n for perl so that I can't get error messages
>> in Swedish. I haven't found anything, not _any_ other language.

> Which messages are you talking about? Those generated by perl itself
> cannot be localised. There has been some discussion of the possibility
> in the past, but (among other things) there's just too much code out
> there that does regex matching on $@ for this to be very practical
> (start with diagnostics.pm, for instance). Most modules don't provide
> localized error messages either.

Yes I mean those generated by perl itself. I would help my son, whom
I'm trying to teach perl, understand what's wrong.


--
MartinS

Klaus <> wrote:
> On 2 déc, 11:52, Martin Str|mberg <a...@sister.ludd.luth.se> wrote:
>> I've been looking for i18n for perl so that I can't get error messages
>> in Swedish. I haven't found anything, not _any_ other language.
>>
>> Is there no such thing? Or have I just searched the wrong places or
>> for the wrong things?

> Have you looked on CPAN ?

> http://search.cpan.org/~audreyt/i18n-0.10/lib/i18n.pm

Hmm, I think so. I don't remember what I searched for, but either I
got 0 results or too many and the top ones wasn't anything I looked
for. I think I looked at that one but dismissed it (then).

Anyway, that is almost what I was looking for. Now all we need is
those ~~ in all perl and the .po files...


Thank you.


--
MartinS

On 2009-12-03, Ben Morrow <> wrote:
> That is for module authors to use to internationalise their modules. It
> doesn't help with the messages perl generates itself.

Thinking about it more:

A) I find the argument that Perl is a "lingua franca of science and
technology" very misplaced. *A Perl application* may be designed
for use by children and/or music lovers.

B) We need something which works as English during parsing, but is
printed out in Bengali. This looks like overloading.

Unfortunately, when I designed overloading, I did not think *at
all* about overloading objects with string semantic. There was
no provision to treat REx matching specially during overloading,
treat print() specially, treat substr() specially, treat index()
specially etc... AFAIK, the current overloading behaves the same
way.

Is there code which analyses $@ any other way than doing =~? If
not, then making overloaded-stringify inspect whether it is
called during REx-matching might me possible (at least with some
modification of perl C code to make the latter condition easier
recognizable...).

Basically, what I think of is making $@ into a 2-headed beast, with 2
different STRING values. What do people think?

Ilya

On 2009-12-10, Ben Morrow <> wrote:
>> Thinking about it more:

>> A) I find the argument that Perl is a "lingua franca of science and
>> technology" very misplaced. *A Perl application* may be designed
>> for use by children and/or music lovers.

> Um, yes? Who are you arguing with?

Whoever wrote this (earlier in the thread).

>> B) We need something which works as English during parsing, but is
>> printed out in Bengali. This looks like overloading.
>>
>> Unfortunately, when I designed overloading, I did not think *at
>> all* about overloading objects with string semantic. There was
>> no provision to treat REx matching specially during overloading,
>
> There is now. I submitted a patch to add 'qr' overloading to 5.12, which
> is called when an overloaded object is used on the RHS of =~ or is
> interpolated into a regex. Since 5.12 has true REGEX SVs, it seemed
> silly not to have a corresponding 'type-cast' overload.

Good. But what I was "hinting at" was the LHS of "=~" ...; which is a
string. And "a string" != "a REx" (after appropriate overloading of !=

>> Basically, what I think of is making $@ into a 2-headed beast, with 2
>> different STRING values. What do people think?

> There was some discussion of this issue on p5p a while ago, though that
> was before qr-overload was different from string-overload. IIRC the
> general feeling was that trying to get people to move away from
> string-matching $@ by defining a set of numeric error codes for the core
> perl errors was probably the best way forward.

I would hate numeric errors.

(When my system boots, there is a chance
of getting an error message which essentially says:

!!! SYS2025
!!! SYS2027

Very enjoyable. (Explanation: the system knows many different ways to
expand these to much more human-readable form. But
the system did not even start booting yet, so has no
idea in which language to bash you...))

I would very much prefer "short descriptive english strings" approach.
ERROR_DISK_READ, ERROR_DISK_NONBOOT would have similar (un)convenience
for paper manual lookup, and would have some chance for the meaning to
be guessed without the manual.[*]

Anyway, this is a pipe dream. The code DOES do $@ =~ /foo/.

Ilya
[*] P.S. On the other hand, one of my friends worked as
"non-customer support" in a certain establishment of
more or less technical nature. Non-customers were kinda
engineers. So a call about the error above might sound like:

The 1st and 3rd symbols look like snakes; the second forks;
then comes number 2025. What to do?

(I did not believe this at first, but this did not sound
like a joke.) In such situation, reducing number of
distinct non-digits to two DOES help...

On 2009-12-11, Ben Morrow <> wrote:
>>[*] P.S. On the other hand, one of my friends worked as
>> "non-customer support" in a certain establishment of
>> more or less technical nature. Non-customers were kinda
>> engineers. So a call about the error above might sound like:
>>
>> The 1st and 3rd symbols look like snakes; the second forks;
>> then comes number 2025. What to do?
>>
>> (I did not believe this at first, but this did not sound
>> like a joke.) In such situation, reducing number of
>> distinct non-digits to two DOES help...
>
> It sounds entirely believable to me, assuming the caller spoke a
> language that doesn't use the Latin alphabet but does use Arabic
> numerals.

Of course. What made is hard to believe is that the country in
question is (at least up to some extend) a part of "extended Europe"
nowadays (IIRC, it takes part in some European sport competitions etc).

And AFAIU the story does not make sense applied to, e.g., Russian-speakers...

Ilya

Ben Morrow <> wrote:
> Quoth Ilya Zakharevich <nospam->:
>> Anyway, this is a pipe dream. The code DOES do $@ =~ /foo/.

> That is the problem, yes.

I'm not a perl implementation hacker, but I have problems seeing the
problem.

We take that i18n module and make it a pragma (if it isn't
already). Or invent a new one. In my example below I've called this
pragma "i18n".

Then if "no i18n" is in effect, which is the default "$@" will be what
it always has been, i. e. in English.

However is a program/module uses the pragma "use i18n Swedish" or "use
i18n svenska" or whatever the syntax should be, then every "$@" in
this block/context (or whatever the term is) will suddenly be in
Swedish. And as the programmer added the "use i18n Swedish" he will be
aware of this so he will match "$@" on Swedish strings.


Perhaps this is already what that i18n module on CPAN does.

And the problem is in the perl implementation code there is a lot
matching "$Â@" on English strings, which are the strings I want to be
Swedish.


Hmm. Perhaps we should just make a perl wrapper (perlint?) that
translates the output from a perl program if it matches a perl error
message, like "perlint Swedish my_perl_script.pl"? Or perhaps only if
the exit status indicates failure?



MartinS

On 2009-12-16, Martin Str|mberg <> wrote:
>>> Anyway, this is a pipe dream. The code DOES do $@ =~ /foo/.

> I'm not a perl implementation hacker, but I have problems seeing the
> problem.
>
> We take that i18n module and make it a pragma (if it isn't
> already). Or invent a new one. In my example below I've called this
> pragma "i18n".

First question: do you understand difference between lexical and
dynamic scope? If you do, which one is your pragma implementing, and
why would this help?

> However is a program/module uses the pragma "use i18n Swedish" or "use
> i18n svenska" or whatever the syntax should be, then every "$@" in
> this block/context (or whatever the term is) will suddenly be in
> Swedish.

What do you mean by "in this block/context"? Created in this context?
Read in this context?

Do you understand that some $@ are created by Perl executable, and
some by scripts? Which do you mean?

> And the problem is in the perl implementation code there is a lot
> matching "$Â@" on English strings, which are the strings I want to be
> Swedish.

Can't parse what you wanted to say...

Yours,
Ilya