> >> 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
In article , Stefan Monnier
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
> the
> 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 alwa
"Stephen J. Turnbull" 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 me
> 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
Emacsweblogs@
> 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
>> 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 wou
>> 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
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 curre
> 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
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
> t
smc 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 t
2010/1/29 Mark A. Hershberger
> smc 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 tra
smc 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 ale
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
interface
15 matches
Mail list logo
