Re: [Emacsweblogs] i18n

Re: [Emacsweblogs] i18n

[smc]

[-- Attachment #1: Type: text/plain, Size: 2081 bytes --]

2010/1/29 Mark A. Hershberger <mah@everybody.org>

> smc <smc@manticore.es> writes:
>
> > I don't know if this approach is the better one.  I always thought that
> > Emacs Lisp itself should implement the Gettext way for translating
> > interfaces.
>
> I like gettext, but I think the better way still is the sort of
> collaborative translation that translateWiki enables.
>
> As I can see, the Translatewiki system is also based in gettext, but with
a web interface, like Drupal does.  Really, the web interface is not the way
for
a good editing job.  Emacs has a powerful PO mode for that, with access
to the source context, and including features for programmers (marking
the translatables strings).

Still it will be necessary to mark the strings in the Weblogger source
files,
and a means for these strings to be recognized and proccesed in the user's
native language.

Gettext proposal is the mark 'gettext' as a standard and a alternative
abbreviation for Lisp code consisting of (_"string")




> I'm a little surprised (now that I've looked) to discover that there is
> no “Emacs-way” to handle i18n and l10n.  Perhaps this is an opportunity
> to make a significant contribution to Emacs.
>
>
The lack of i18n/l10n from Emacs is a _real_tragedy_ for the Software Libre
world and for the entire computer users community.  As an example, we are
a very small Canary Islands based company.  We all use GNU Emacs and
our customers from scholar/academic scene -that are good profesionals in
areas such as literature, historiography, psychology- are not technical
users
and most of them do not speak English, but French (in case they really know
a second language).  It is a deep misconception to think that Emacs is not
for this kind of people.  With Emacs, we could solve a very large range of
their needs.  (Emacs is also for _the secretaries_, Stallman said in 1981;
this
is our starting point, but not only for English secretaries, I suppose.)



> Patches welcome!
>
> Mark.
>
>


-- 
Suso
http://gnu.manticore.es

[-- Attachment #2: Type: text/html, Size: 3598 bytes --]

Re: [Emacsweblogs] i18n

[Mark A. Hershberger]

smc <smc@manticore.es> writes:

> As I can see, the Translatewiki system is also based in gettext, but with
> a web interface, like Drupal does.

It doesn't use gettext() but the system is based on gettext().

And the point is not the UI.  The point is the number of people who work
on translateWiki and can produce translations in multiple languages
quickly.

If you prefer something more emacsy, I'm sure that can be done.  I
certainly prefer emacs: I have a mediawiki.el mode for writing wiki pages.

I don't know enough to say whether _"string" is a viable way to mark up
text in Emacs Lisp, but my first guess is that it isn't — not without
work done to the internals.

However, we could define a _ function so that we can wrap strings like
this:

    (_ "message")

Which wouldn't be a simple, but could work.

> It is a deep misconception to think that Emacs is not for this kind of
> people.  With Emacs, we could solve a very large range of their needs.
> (Emacs is also for _the secretaries_, Stallman said in 1981; this is
> our starting point, but not only for English secretaries, I suppose.)

I hope not!

If I can help emacs use spread to non-English-speaking secretaries by
providing a multi-lingual weblogger.el, I'm all for it!

Mark.

-- 
http://hexmode.com/

The only alternative to Tradition is bad tradition.
                          — Jaraslov Pelikan

Re: [Emacsweblogs] i18n

[Stephen J. Turnbull]

Mark A. Hershberger writes:

 > I don't know enough to say whether _"string" is a viable way to mark up
 > text in Emacs Lisp, but my first guess is that it isn't -- not without
 > work done to the internals.

It's not.

 > However, we could define a _ function so that we can wrap strings like
 > this:
 > 
 >     (_ "message")
 > 
 > It wouldn't be a simple, but could work.

Oh, that's simple enough, and would work.  IMHO, it's way too ugly,
though.  If you're going to do that, you might as well just

(defun gettext (message &optional domainname category) ...)

(see gettext(3) for the optional arguments, taken from dcgettext) and
use that.  Perhaps more (Common) Lispy would be keyword arguments,
with the idea of building them into an internationalized version of
format (and a fortiori message and princ y amigos).  And once you've
got `gettext', (defsubst _ (&rest args) (apply #'gettext args)) is
easy and efficient if you really must have it.

What would probably be best if you want reader syntax for this would
be some variation on #_"string".  This would also require work on the
internals, but wouldn't be that hard to do.  The question is "Too
ugly?"

Re: [Emacsweblogs] i18n

[Juri Linkov]

> The question is "Too ugly?"

Perhaps less ugly would be not to add special markers to each and every
message, but to translate existing messages internally (e.g. in the
function `message', in functions that display menus or doc-strings)
depending on the current language environment like `tutorial' does
automatically selecting the language of the tutorial.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: [Emacsweblogs] i18n

[Stephen J. Turnbull]

Juri Linkov writes:
 > > The question is "Too ugly?"
 > 
 > Perhaps less ugly would be not to add special markers to each and every
 > message, but to translate existing messages internally (e.g. in the
 > function `message', in functions that display menus or doc-strings)
 > depending on the current language environment like `tutorial' does
 > automatically selecting the language of the tutorial.

The problem is that the *human* translators need the markers to know
what to translate.

Re: [Emacsweblogs] i18n

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Feb 01, 2010 at 10:22:50PM +0900, Stephen J. Turnbull wrote:
> Juri Linkov writes:
>  > > The question is "Too ugly?"
>  > 
>  > Perhaps less ugly would be not to add special markers to each and every
>  > message, but to translate existing messages internally [...]

> The problem is that the *human* translators need the markers to know
> what to translate.

...and then there are menus and other things. You'd have to locate every
function bound to display a user-facing string (and what do you do about
messages being "synthesised" programatically?).

I think it does make sense to mark the strings themselves: "this is a
translatable string".

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFLZxm0Bcgs9XrR2kYRApcyAJ9fqfwqHbdTq80l9GxnJTnhEQUcRwCfQldH
8parkqxpnGSB6yV6U2W3RY0=
=lM0j
-----END PGP SIGNATURE-----

Re: [Emacsweblogs] i18n

[Andreas Schwab]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> The problem is that the *human* translators need the markers to know
> what to translate.

The translators don't work with the source files, they work with the po
files.  The markers are necessary for the pot creator, but as the GCC
example shows there are other methods besides marking the translatable
strings explicitly.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: i18n

[Juri Linkov]

> The problem is that the *human* translators need the markers to know
> what to translate.

I like very much how the translation process is organized in Drupal.
In addition to using gettext, at the time an untranslated string is
displayed it dynamically gets added to the database.  Later it can be
translated using UI to search for untranslated strings and translate
them.  It's possible to export translated strings in the .po format.
http://drupal.org/handbook/modules/locale

But in the source code, strings are still explicitly marked by special markers.
An alternative to marking translatable strings is to use a regexp-based
approach like is used by `debug-ignored-errors'.  For a message format
like "Can't find the %s manpage" it uses a regexp to match its variable part
like "^Can't find the .* manpage$".  However, performance wise this approach
doesn't seem optimal.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: [Emacsweblogs] i18n

[Stefan Monnier]

>> I don't know enough to say whether _"string" is a viable way to mark up
>> text in Emacs Lisp, but my first guess is that it isn't -- not without
>> work done to the internals.
> It's not.

It would be easy to change the reader such that _"foo" is automatically
read as (_ "foo"), just like we do for 'foo -> (quote foo).


        Stefan

RE: [Emacsweblogs] i18n

[Drew Adams]

> It would be easy to change the reader such that _"foo" is 
> automatically read as (_ "foo"), just like we do for 'foo -> (quote foo).

Oh sure. And break existing code.

It might be easy to change the reader to do that.
But why?  What's really gained by such a change?

Lisp (in general) has always read + eval'd a sexp such as (list 'foo_"bar") to
produce the list (foo_ "bar"). You would have it return (foo (_ "bar"))?

Caveat: I haven't followed this thread. I thought the question was about markup.
Why would a feature request for markup make us want to change the Lisp reader?
Apologies if I misunderstand the suggestion.

Re: i18n

[Stefan Monnier]

>> It would be easy to change the reader such that _"foo" is 
>> automatically read as (_ "foo"), just like we do for 'foo -> (quote foo).
> Oh sure. And break existing code.

I grepped for this sequence before sending the previous email.  So while
theoretically there may be code out there that would be affected,
I don't think such code really exists in practice.

> Lisp (in general) has always read + eval'd a sexp such as (list
> 'foo_"bar") to produce the list (foo_ "bar"). You would have it return
> (foo (_ "bar"))?

Actually, I'd probably have it return the same as now because this _
appears in the "middle" (well, the end) of a symbol.  This said, I do not
think there is this kind of code in the wild either,


        Stefan

RE: [Emacsweblogs] i18n

[Drew Adams]

> >> It would be easy to change the reader such that _"foo" is 
> >> automatically read as (_ "foo"), just like we do for 'foo 
> >> -> (quote foo).
> >
> > Oh sure. And break existing code.
> 
> I grepped for this sequence before sending the previous 
> email.  So while theoretically there may be code out there
> that would be affected, I don't think such code really exists
> in practice.

So should we specialize the Lisp reader to only support whatever is currently
found in the existing Emacs source code, disallowing other legitimate Lisp
syntax because it doesn't "really exist in practice"?

> > Lisp (in general) has always read + eval'd a sexp such as (list
> > 'foo_"bar") to produce the list (foo_ "bar"). You would 
> > have it return (foo (_ "bar"))?
> 
> Actually, I'd probably have it return the same as now because this _
> appears in the "middle" (well, the end) of a symbol.  This 
> said, I do not think there is this kind of code in the wild either,

So you would change the Lisp reader to do something quite different from
traditional Lisp readers, because you don't think the code they support is, in
this case, likely to be encountered. That's your argument, apparently.

You still haven't given a good reason for making such a change:

> > But why?  What's really gained by such a change?

So far your argument seems to be:

1. It's easy to do, so let's do it.

2. There's no existing code that uses the currently supported syntax, so let's
change it.

By those same arguments alone, we could justify all kinds of nutty reader
changes. How about a _good_ reason? What is to be gained by it?

Re: i18n

[Stefan Monnier]

> You still haven't given a good reason for making such a change:

It's just to keep the annotation as lightweight as possible, since it's
likely to be used at *many* places (in the long run).


        Stefan

Re: [Emacsweblogs] i18n

[Kenichi Handa]

In article <jwvpr4o8zq8.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> It would be easy to change the reader such that _"foo" is 
>>> automatically read as (_ "foo"), just like we do for 'foo -> (quote foo).
> > Oh sure. And break existing code.

> I grepped for this sequence before sending the previous email.  So while
> theoretically there may be code out there that would be affected,
> I don't think such code really exists in practice.

> > Lisp (in general) has always read + eval'd a sexp such as (list
> > 'foo_"bar") to produce the list (foo_ "bar"). You would have it return
> > (foo (_ "bar"))?

> Actually, I'd probably have it return the same as now because this _
> appears in the "middle" (well, the end) of a symbol.  This said, I do not
> think there is this kind of code in the wild either,

Currently #("bar") is read as "bar".  How about reading it
as "#("bar" 0 3 (gettext t))?  Then, we don't have to
introduce any new syntax.

---
Kenichi Handa
handa@m17n.org