unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Jean-Christophe Helary <jean.christophe.helary@gmail.com>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: Eli Zaretskii <eliz@gnu.org>, Emacs-devel@gnu.org
Subject: Re: Before l10n, better practices for (message) ?
Date: Thu, 25 May 2017 07:35:07 +0900	[thread overview]
Message-ID: <1BF0657B-5A1E-4527-AACC-54E5224C5DB7@gmail.com> (raw)
In-Reply-To: <26eb65ca-4a37-e707-8090-428fd70ac695@cs.ucla.edu>


> On May 25, 2017, at 7:09, Paul Eggert <eggert@cs.ucla.edu> wrote:
> 
> On 05/24/2017 12:12 PM, Eli Zaretskii wrote:
>> He most probably wanted to point out that any infrastructure of
>> this kind should at least consider using gettext, if not actually use
>> it.
> 
> There is no point to straightening up strings if we don't have a translation infrastructure.

As the title suggests I was talking about better practices for UI messages regardless of whether we do l10n or not.
i18n and l10n are one thing, but having manageable strings that don't generate grammatical errors because developers consider elisp as a macro language for Natural Languages is a different thing.

It is not even a chicken and egg situation. Fixing strings and setting rules for developers will benefit all users right now. And we can also work on i18n, which is a totally different thing and requires a skill set that I'm pretty sure I don't have right now (while figuring out what a complex concat does is reasonably within what I can do right now).

> In contrast, it would be helpful to have the infrastructure even if some strings still need straightening up, because the other strings will be translated.

It would be helpful to have a lot of things. But l10n has been discussed for a while here and nobody is working on it as far as I can tell.

> This suggests that we should focus our initial efforts on getting the infrastructure up, and worry about straightening up strings later. That is why I suggested gettext in response to your question about where we should start.

No, this suggests that if you're interested in leading the i18n efforts, you can go ahead.

And as I just wrote to Eli, I'm fine with helping in that area but there are people who are much more qualified in terms of experience with Emacs and Elisp. My priority right now is to learn about Emacs and Elisp while helping where I can, and that does not include creating a full i18n infrastructure on my own.

Jean-Christophe 


  reply	other threads:[~2017-05-24 22:35 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-22 23:30 Before l10n, better practices for (message) ? Jean-Christophe Helary
2017-05-23  0:59 ` Tino Calancha
2017-05-23  1:18   ` Jean-Christophe Helary
2017-05-23  2:55     ` Eli Zaretskii
2017-05-23  3:38       ` Jean-Christophe Helary
2017-05-23 18:36         ` Eli Zaretskii
2017-05-23 22:00           ` Jean-Christophe Helary
2017-05-24  2:32             ` Eli Zaretskii
2017-05-24  2:40               ` Jean-Christophe Helary
2017-05-24  4:22                 ` Paul Eggert
2017-05-24  8:08                   ` Jean-Christophe Helary
2017-05-24 19:12                     ` Eli Zaretskii
2017-05-24 21:29                       ` Jean-Christophe Helary
2017-05-26  3:50                         ` Richard Stallman
2017-05-24 22:09                       ` Paul Eggert
2017-05-24 22:35                         ` Jean-Christophe Helary [this message]
2017-05-26  8:07                           ` Eli Zaretskii
2017-05-24 23:51                         ` Jean-Christophe Helary
2017-05-23  7:52       ` Jean-Christophe Helary
2017-05-23 18:42         ` Eli Zaretskii
2017-05-23 22:03           ` Jean-Christophe Helary
2017-05-26  8:14             ` Eli Zaretskii
2017-05-26 14:21               ` Jean-Christophe Helary
2017-05-26 14:44                 ` Eli Zaretskii
2017-05-26 18:08                   ` Yuri Khan
2017-05-26 19:00                     ` Eli Zaretskii
2017-05-27  1:52                       ` Jean-Christophe Helary
2017-05-26 18:54               ` Etienne Prud’homme
2017-05-26 19:06                 ` Eli Zaretskii
2017-05-26 19:15                   ` Etienne Prud’homme
2017-05-26 19:27                     ` Eli Zaretskii
2017-05-26 21:57                       ` Etienne Prud’homme
2017-05-27  7:22                         ` Eli Zaretskii
2017-05-27  1:16                 ` Jean-Christophe Helary
2017-05-27  7:43                   ` Eli Zaretskii
2017-05-27  4:08       ` Marcin Borkowski
2017-05-27  7:49         ` Eli Zaretskii
2017-05-28  4:00           ` Marcin Borkowski
2017-05-27 23:27         ` Göktuğ Kayaalp
2017-05-28  0:44           ` Jean-Christophe Helary
2017-05-28 14:44             ` Göktuğ Kayaalp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1BF0657B-5A1E-4527-AACC-54E5224C5DB7@gmail.com \
    --to=jean.christophe.helary@gmail.com \
    --cc=Emacs-devel@gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).