unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Jean-Christophe Helary <jean.christophe.helary@gmail.com>
To: emacs-devel <emacs-devel@gnu.org>
Subject: Re: Before l10n, better practices for (message) ?
Date: Sun, 28 May 2017 09:44:35 +0900	[thread overview]
Message-ID: <58C239AA-C9A8-4C9A-9035-8F897A133B83@gmail.com> (raw)
In-Reply-To: <ygm1sr9c23g.fsf@xi>


> On May 28, 2017, at 8:27, Göktuğ Kayaalp <self@gkayaalp.com> wrote:

Göktuğ,

Thank you for your mail. You raise very important questions, that are not really technical in nature (ie they are not solvable with technology only). But we need to solve legitimate technical issues before worrying.

What you describe is common to all l10n endeavor and I think very big projects (Debian for ex) have already shown that we can find solutions. As a translator who's participated to FOSS translations for the last 20 years (besides for paying my bills with non-FOSS/non-fun translations for about the same time), I am positive that a l10n effort will only bring good things to Emacs in general, even if it puts a slight burden on the development community. But if we find the right solutions, it won't be more effort than other projects have to handle.

> - Some packages will have translations, some won't, and thus some
>  messages will be in my language, and some English, which will be
>  confusing (and annoying).
> 
> - The manuals will have to be translated too.

Once the infrastructure exists, I believe Emacs has such a name recognition that creating (or getting support from already existing) l10n groups will be relatively easy, especially since existing groups don't work on Emacs simply because Emacs does not provide the proper mechanism for l10n.

> - It will undermine online discussion, as people will start posting
>  (error) messages in their locales, and others will have to decode
>  them.  Also, using online documentation will become harder as now one
>  will need to translate.

Just as with all the big l10n projects, we will have native communities that will handle the issues in native language. This works already. There are already Emacs experts in all languages so there is little to worry about. I think when Emacs gets i18n/l10n there will be a huge amount of enthusiasm in the *whole* FOSS world.

> - Emacs probably has way more strings to be translated than most
>  applications out there, which will hinder the translations and make it
>  more error prone.  Also, the community is not large enough that the
>  messages will always be up-to-date and correct.

Here again, the existing native language groups have the infrastructure to cope with that. I am not worried.

I have a po4a based estimate for the existing documentation: the Emacs/Elisp/Introduction manuals are about 900,000 words (180 man/day). The various modes that are included in the distribution are about 700,000 words (140 man/day). I estimate that the UI strings are at most 15% of the total written mode manuals (no way to get the strings from the code right now), counting all the redundancy between the manuals and the package inline documentation, so the strings themselves would be at about 100,000 (20 man/day).

With 10 translation volunteers, that represents 34 days of work. With only 1 day per week, that's about 10 months, let's say 1 year to account for coordination, checking etc. It really is not that much of a task. And once that is done, the amount of new strings is really low. Such volunteers do not need to be Emacs experts. They need to be Emacs users and be involved in their native language l10n effort. It will be easy for them to translate (I can tell since I am not an Emacs/Elisp expert but have little difficulty working on the French translation). Plus the translation effort will find a lot of issues in the documentation, so even the English community will benefit from it.

> I believe most users would just use Emacs in English even if the strings
> were translated, as many have their LC_MESSAGES or entire OS in English:
> It's just more convenient for a power user.

People who *easily* work in English are not the target of the l10n effort. The l10n effort will allow for the creation of native communities about Emacs/Elisp which do not exist at the moment (or are limited to power users).

> The Emacs community is
> mostly anglophone already anyways, and I doubt having translations will
> change that at all.

The Emacs development community will not be affected by the changes.

> Also, given the size of our community and the amount of work (translating Emacs is translating a programming language runtime + a collection of applications), it may result to be too much of a burden on it.

See above.

> Nevertheless, if translations happen, I'll try to help with Turkish (my
> mother tongue) translations.  And please excuse me if I weren't supposed
> to post here as I'm not the most experienced user and have only a bunch
> of patches in Emacs.

Thank you very much for your concern. I am not even a power user and I've contributed only a few lines to Emacs. If you are interested in the internationalization effort, please join the discussion and help. Other projects have shown that l10n efforts add a little overhead (considering the whole development effort) but also brings huge benefits related to FOSS adoption. Let's work on how to make that a reality!


Jean-Christophe 


  reply	other threads:[~2017-05-28  0:44 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
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 [this message]
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=58C239AA-C9A8-4C9A-9035-8F897A133B83@gmail.com \
    --to=jean.christophe.helary@gmail.com \
    --cc=emacs-devel@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).