[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: format use inquiry
Re: format use inquiry
Sun, 2 Jul 2017 10:35:20 +0900
> On Jul 2, 2017, at 0:43, Drew Adams <address@hidden> wrote:
> My mention of (the -P flag in CL) was essentially off-topic for your
> thread about localization. (But it could still be
> somewhat on-topic for a thread about `format'.)
This thread happens to be about "format", as the title and original exchanges
I was explicitly asking about a specific use of format in url creation that has
no relation to l10n and got several replies ranging from "don't spell out the
urls" to "do spell out the urls"...
After reviewing the whole emacs lisp code found in the distribution I found
that no other files in the whole distribution used a format trick to add an "s"
to "http" when creating "https" urls (especially *none* of the code that was
heavily used for https etc.), and I also found that all the places where both
http and https urls were present they were all fully spelled out.
So considering that even if the code is valid and considered acceptable, 1)
general use of 40 years of elisp having not produced such distribution code and
2) the package.el code being ridden with such "smart uses" of format/concat and
the like that in fact created errors in external strings (I did not check the
internal strings), the conclusion was that such code should be fixed so that
other developers who check it don't get bad ideas. Unless you have more
powerful arguments, that kind of settles the issue for me.
In a different thread I also mentioned that I started straightening out strings
in package.el because I had found plural/singular errors in it fully *knowing*
that i18n is not available so that any "micro" l10n preparation of this type is
bound to not be super useful *right now*, but currently that's the only part
where I can contribute (I put aside the few lines of trivial code that I was
allowed to contribute in ns-win and subr-x).
What I want to reach is a state where Emacs is fully localizable. There are
many entry points and few people interested in producing relevant code, so I
have to do with what I have (no knowledge of C but I'm starting to work on
that, little knowledge of elisp, 20 years of localization work as an amateur in
FOSS projects, 15 as a professional).
Last June, Philipp Stephani has implemented "field numbers for `format' so that
argument indices can be explicitly specified" to take care of word order
modifications (among other issues). I don't think a lot of people have started
using that but that's an excellent and necessary start. We need a way to
gettext to extract external strings, we need a way to display localized
strings, we need to straighten out strings so that they are extractable by
gettext and we need to localize them (including docstrings eventually). l10n
itself is a huge endeavor: based on the state of the manuals, I'm estimating
the volume at 500,000 words for the code alone, and 2,000,000 words total when
including the manual. So the code that allows for that is actually a relatively
small part of the work. But without the code, we're stuck.
So if you have an interest in the endeavor and concrete ideas, please come
forward: do as Philipp did by producing relevant code, or do as I do, by fixing
little things that will need to be fixed anyway.