i18n

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

i18n

smc-3

It would very convenient to translate the user interface into other languages.

The Emacs mp3player implement this through a file consisting of lists.

I don't know if this approach is the better one.  I always thought that Emacs Lisp itself should implement the Gettext way for tranlating interfaces.


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

_______________________________________________
Emacsweblogs mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/emacsweblogs
Reply | Threaded
Open this post in threaded view
|

Re: i18n

Mark A. Hershberger
smc <[hidden email]> 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 tranlating
> interfaces.

I like gettext, but I think the better way still is the sort of
collaborative translation that translateWiki enables.

(Bias alert: I'm working on a Mediawiki contract for Wikimedia.
Translatewiki was originally developed to help with Mediawiki
translation.)

Check out http://translatewiki.net/sw/Project_list for software projects
other than Mediawiki that are using the site to translate their
software.

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.

Patches welcome!

Mark.



--
http://hexmode.com/

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


_______________________________________________
Emacsweblogs mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/emacsweblogs
Reply | Threaded
Open this post in threaded view
|

Re: i18n

smc-3




2010/1/29 Mark A. Hershberger <[hidden email]>
smc <[hidden email]> 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

_______________________________________________
Emacsweblogs mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/emacsweblogs
Reply | Threaded
Open this post in threaded view
|

Re: i18n

Mark A. Hershberger
smc <[hidden email]> 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


_______________________________________________
Emacsweblogs mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/emacsweblogs
Reply | Threaded
Open this post in threaded view
|

Re: 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?"



_______________________________________________
Emacsweblogs mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/emacsweblogs
Reply | Threaded
Open this post in threaded view
|

Re: 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/


_______________________________________________
Emacsweblogs mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/emacsweblogs
Reply | Threaded
Open this post in threaded view
|

Re: 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.



_______________________________________________
Emacsweblogs mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/emacsweblogs
Reply | Threaded
Open this post in threaded view
|

Re: i18n

Stefan Monnier
In reply to this post by Stephen J. Turnbull
>> 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


_______________________________________________
Emacsweblogs mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/emacsweblogs
Reply | Threaded
Open this post in threaded view
|

Re: i18n

Andreas Schwab-2
In reply to this post by Stephen J. Turnbull
"Stephen J. Turnbull" <[hidden email]> 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, [hidden email]
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


_______________________________________________
Emacsweblogs mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/emacsweblogs
Reply | Threaded
Open this post in threaded view
|

RE: i18n

Drew Adams
In reply to this post by 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.

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.



_______________________________________________
Emacsweblogs mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/emacsweblogs
Reply | Threaded
Open this post in threaded view
|

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


_______________________________________________
Emacsweblogs mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/emacsweblogs
Reply | Threaded
Open this post in threaded view
|

RE: 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?



_______________________________________________
Emacsweblogs mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/emacsweblogs
Reply | Threaded
Open this post in threaded view
|

Re: i18n

Juri Linkov
In reply to this post by Stephen J. Turnbull
> 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/


_______________________________________________
Emacsweblogs mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/emacsweblogs
Reply | Threaded
Open this post in threaded view
|

Re: i18n

Stefan Monnier
In reply to this post by Drew Adams
> 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


_______________________________________________
Emacsweblogs mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/emacsweblogs
Reply | Threaded
Open this post in threaded view
|

Re: i18n

Kenichi Handa
In reply to this post by Stefan Monnier
In article <[hidden email]>, Stefan Monnier <[hidden email]> 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
[hidden email]




_______________________________________________
Emacsweblogs mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/emacsweblogs