Localized org-mode

Localized org-mode

[ST]

Hello,

is there something like localized/internationalized org? I.e. all
keywords, like :PROPERTIES: are translated to another language,
like :EIGENSCHAFTEN: (for German) so it looks more natural in a foreign
language. It is of a special importance for languages with non-latin
letters, where the mix of different languages might be
visually/esthetically disturbing and require switching of keyboard
layouts while writing. Technically it should be a simple 1-to-1
substitution based on an org_keyword_vocabulary for a specific language.

Thank you!

Re: Localized org-mode

[Nicolas Goaziou]

Hello,

ST <smntov@gmail.com> writes:

> is there something like localized/internationalized org? I.e. all
> keywords, like :PROPERTIES: are translated to another language,
> like :EIGENSCHAFTEN: (for German) so it looks more natural in a foreign
> language. It is of a special importance for languages with non-latin
> letters, where the mix of different languages might be
> visually/esthetically disturbing and require switching of keyboard
> layouts while writing. Technically it should be a simple 1-to-1
> substitution based on an org_keyword_vocabulary for a specific
> language.

:PROPERTIES: is part of the Org syntax. Having it translated would make
it more difficult for the parser to operate, and possibly break
compatibility between documents written in different languages.

IMO, having PROPERTIES, and a few other keywords, is a minor annoyance.
For example, you never need to actually write "PROPERTIES" since `C-c
C-x p' (`org-set-property') creates it for you. Also, `C-c C-e #'
(`org-export-insert-default-template') inserts many keywords for you.

Regards,

-- 
Nicolas Goaziou

Re: Localized org-mode

[ST]

> > is there something like localized/internationalized org? I.e. all
> > keywords, like :PROPERTIES: are translated to another language,
> > like :EIGENSCHAFTEN: (for German) so it looks more natural in a foreign
> > language. It is of a special importance for languages with non-latin
> > letters, where the mix of different languages might be
> > visually/esthetically disturbing and require switching of keyboard
> > layouts while writing. Technically it should be a simple 1-to-1
> > substitution based on an org_keyword_vocabulary for a specific
> > language.
> 
> :PROPERTIES: is part of the Org syntax. Having it translated would make
> it more difficult for the parser to operate, and possibly break
> compatibility between documents written in different languages.

Why? Run "detranslator" before you start parsing. I.e. based on your
1-to-1 vocabulary "detranslator" will substitute all :EIGENSCHAFTEN: and
all other org syntax back to English :PROPERTIES: etc.. Then apply
parser as usual.

> 
> IMO, having PROPERTIES, and a few other keywords, is a minor annoyance.
> For example, you never need to actually write "PROPERTIES" since `C-c
> C-x p' (`org-set-property') creates it for you. Also, `C-c C-e #'
> (`org-export-insert-default-template') inserts many keywords for you.

Writing is only a half of the problem. Imagine Cyrillic or Chinese text
mixed with Latin letters. Org is not html (that hides its syntax once
rendered) and it is supposed to be smoothly readable in raw plain text
form. Even worth - imagine right-to-left texts like Hebrew or Persian
mixed up with left-to-right Latin letters. It's not aesthetical.

Thank you!

Re: Localized org-mode

[Nicolas Goaziou]

ST <smntov@gmail.com> writes:

> Why? Run "detranslator" before you start parsing. I.e. based on your
> 1-to-1 vocabulary "detranslator" will substitute all :EIGENSCHAFTEN: and
> all other org syntax back to English :PROPERTIES: etc.. Then apply
> parser as usual.

You cannot blindly replace all ":EIGENSCHAFTEN:" with ":PROPERTIES:"
because some of them could be real ":EIGENSCHAFTEN:", which is valid
syntax. IOW, you need to parse the buffer to know what ":EIGENSCHAFTEN:"
ought to be replaced, so you're running in circles.

> Writing is only a half of the problem. Imagine Cyrillic or Chinese text
> mixed with Latin letters. Org is not html (that hides its syntax once
> rendered) and it is supposed to be smoothly readable in raw plain texta
> form. Even worth - imagine right-to-left texts like Hebrew or Persian
> mixed up with left-to-right Latin letters. It's not aesthetical.

If that's an aesthetic issue, we could fix it on the aesthetic side.

For example, you can localize timestamps with `org-display-custom-times'
and `org-time-stamp-custom-formats'. It could be possible to do
something similar, i.e., to use overlays, e.g., on top of properties
drawers. Of course, this wouldn't change the underlying appearance, but
the solution is much less invasive than what you suggest.

Do you want to propose a patch?

Re: Localized org-mode

[ST]

On Tue, 2018-05-08 at 20:21 +0200, Nicolas Goaziou wrote:
> ST <smntov@gmail.com> writes:
> 
> > Why? Run "detranslator" before you start parsing. I.e. based on your
> > 1-to-1 vocabulary "detranslator" will substitute all :EIGENSCHAFTEN: and
> > all other org syntax back to English :PROPERTIES: etc.. Then apply
> > parser as usual.
> 
> You cannot blindly replace all ":EIGENSCHAFTEN:" with ":PROPERTIES:"
> because some of them could be real ":EIGENSCHAFTEN:", which is valid
> syntax. IOW, you need to parse the buffer to know what ":EIGENSCHAFTEN:"
> ought to be replaced, so you're running in circles.

So how do you solve this problem now for English ":PROPERTIES:"?

Anyway if somebody runs into it he could have at least to options:

1. write local .emacs.d/.org-de-vocabulary which will override the
default one (or parts of it) with a synonym, like:
PROPERTIES -> ATTRIBUTEN
or
PROPERTIES -> ORG_EIGENSCHAFTEN
and then you can replace blindly before parsing.

2. just go back to using English org-vocabulary as it is done now.


> > Writing is only a half of the problem. Imagine Cyrillic or Chinese text
> > mixed with Latin letters. Org is not html (that hides its syntax once
> > rendered) and it is supposed to be smoothly readable in raw plain texta
> > form. Even worth - imagine right-to-left texts like Hebrew or Persian
> > mixed up with left-to-right Latin letters. It's not aesthetical.
> 
> If that's an aesthetic issue, we could fix it on the aesthetic side.
> 
> For example, you can localize timestamps with `org-display-custom-times'
> and `org-time-stamp-custom-formats'. It could be possible to do
> something similar, i.e., to use overlays, e.g., on top of properties
> drawers. Of course, this wouldn't change the underlying appearance, but
> the solution is much less invasive than what you suggest.
> 
> Do you want to propose a patch?

I don't know lisp :(

Re: Localized org-mode

[Nicolas Goaziou]

Hello,

ST <smntov@gmail.com> writes:

> So how do you solve this problem now for English ":PROPERTIES:"?

Simple. Org does not replace anything arbitrarily. This is less
error-prone.

> Anyway if somebody runs into it he could have at least to options:
>
> 1. write local .emacs.d/.org-de-vocabulary which will override the
> default one (or parts of it) with a synonym, like:
> PROPERTIES -> ATTRIBUTEN
> or
> PROPERTIES -> ORG_EIGENSCHAFTEN
> and then you can replace blindly before parsing.

Again, I'm not particularly fond of having conditional syntax like this.

> I don't know lisp :(

You may want to look at `org-display-custom-time'.

Basically, you search for the regexp "^[ \t]*:\\(PROPERTIES\\):", and
use `put-text-property' to change the text between (match-beginning 1)
and (match-end 1), e.g.,

    (defun my-properties-translate ()
      (org-with-point-at 1
        (while (re-search-forward "^[ \t]*:\\(PROPERTIES\\):" nil t)
          (put-text-property (match-beginning 1) (match-end 1) 'display "ATTRIBUTEN"))))

You need to add this function to, e.g. `org-mode-hook'. Of course this
is really basic and can be improved.

Regards,

-- 
Nicolas Goaziou                                                0x80A93738

Re: Localized org-mode

[Diego Zamboni]

[-- Attachment #1: Type: text/plain, Size: 1835 bytes --]

I really don't see the point of trying to localize org keywords. To me,
they are like the keywords in any programming language - part of the
language. Would you consider translating C or LISP keywords?

In addition to the trouble of supporting something like this within Emacs,
think of the growing ecosystem of tools which support org mode - they would
all need to be aware of these localizations. It would be a nightmare to
maintain.

--Diego

On Wed, May 9, 2018 at 10:19 AM, Nicolas Goaziou <mail@nicolasgoaziou.fr>
wrote:

> Hello,
>
> ST <smntov@gmail.com> writes:
>
> > So how do you solve this problem now for English ":PROPERTIES:"?
>
> Simple. Org does not replace anything arbitrarily. This is less
> error-prone.
>
> > Anyway if somebody runs into it he could have at least to options:
> >
> > 1. write local .emacs.d/.org-de-vocabulary which will override the
> > default one (or parts of it) with a synonym, like:
> > PROPERTIES -> ATTRIBUTEN
> > or
> > PROPERTIES -> ORG_EIGENSCHAFTEN
> > and then you can replace blindly before parsing.
>
> Again, I'm not particularly fond of having conditional syntax like this.
>
> > I don't know lisp :(
>
> You may want to look at `org-display-custom-time'.
>
> Basically, you search for the regexp "^[ \t]*:\\(PROPERTIES\\):", and
> use `put-text-property' to change the text between (match-beginning 1)
> and (match-end 1), e.g.,
>
>     (defun my-properties-translate ()
>       (org-with-point-at 1
>         (while (re-search-forward "^[ \t]*:\\(PROPERTIES\\):" nil t)
>           (put-text-property (match-beginning 1) (match-end 1) 'display
> "ATTRIBUTEN"))))
>
> You need to add this function to, e.g. `org-mode-hook'. Of course this
> is really basic and can be improved.
>
> Regards,
>
> --
> Nicolas Goaziou                                                0x80A93738
>
>

[-- Attachment #2: Type: text/html, Size: 2622 bytes --]

Re: Localized org-mode

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 880 bytes --]

Hello all,

On Wed, May 9, 2018, 8:01 AM Diego Zamboni <diego@zzamboni.org> wrote:

> I really don't see the point of trying to localize org keywords. To me,
> they are like the keywords in any programming language - part of the
> language. Would you consider translating C or LISP keywords?
>
> In addition to the trouble of supporting something like this within Emacs,
> think of the growing ecosystem of tools which support org mode - they would
> all need to be aware of these localizations. It would be a nightmare to
> maintain.
>

So much +1 on that! Supporting multi-language keywords will make it
difficult for 3rd party Org parsers to adopt them too, resulting in even
lesser Org adoption.

I like Nicolas' idea where display properties are used to replace the
English keywords with the translation; that way the actual Org source
remains untouched.

> --

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1447 bytes --]

Re: Localized org-mode

[Jean-Christophe Helary]

[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]



> On May 9, 2018, at 21:07, Kaushal Modi <kaushal.modi@gmail.com> wrote:
> 
> Hello all,
> 
> On Wed, May 9, 2018, 8:01 AM Diego Zamboni <diego@zzamboni.org <mailto:diego@zzamboni.org>> wrote:
> I really don't see the point of trying to localize org keywords. To me, they are like the keywords in any programming language - part of the language. Would you consider translating C or LISP keywords?

There are no practical reasons why that should not be possible. The current state of affairs is only due to design constraints when the languages were conceived.

In Scheme, for ex. you can actually redefine all the language keywords very easily without any impact on the interpreter.

> In addition to the trouble of supporting something like this within Emacs, think of the growing ecosystem of tools which support org mode - they would all need to be aware of these localizations. It would be a nightmare to maintain.

Localization, when properly done is never a nightmare to maintain.

> So much +1 on that! Supporting multi-language keywords will make it difficult for 3rd party Org parsers to adopt them too, resulting in even lesser Org adoption.

Genuine question: how many 3rd party tools do support the org format ?

> I like Nicolas' idea where display properties are used to replace the English keywords with the translation; that way the actual Org source remains untouched. 

What matters is that users find org easy to use in their language. But emacs (the main org user) is so far behind in that respect compared to the rest of the FLOSS ecosystem that even having one mode that implements some sort of l10n would be huge. Although, it would be nice to have that work nicely with already existing l10n processes. 


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune



[-- Attachment #2: Type: text/html, Size: 4204 bytes --]

Re: Localized org-mode

[Nicolas Goaziou]

Hello,

Jean-Christophe Helary <brandelune@gmail.com> writes:

> There are no practical reasons why that should not be possible.

Yet, I gave some already. Consider the following three documents:

    * Headline
    :PROPERTIES:
    foo
    :END:

and

    * Headline
    :PROPERTIES:
    :foo:
    :END:

    Paragraph.

    :PROPERTIES:
    bar
    :END:

and

    * Headline
    :PROPRIÉTÉS:
    :foo:
    :FIN:

How would you translate them into, say, French? Can you do this without
knowing what is a properties drawer, including the "PROPERTIES" name?

> The current state of affairs is only due to design constraints when
> the languages were conceived.

So, this is a practical reason: design constraints.

> In Scheme, for ex. you can actually redefine all the language keywords
> very easily without any impact on the interpreter.

Note that Org syntax is more complicated than Scheme's. In both cases,
you need to recognize syntax data before translating them. You do not
really change syntax, you add a layer on top of it.

> What matters is that users find org easy to use in their language. But
> emacs (the main org user) is so far behind in that respect compared to
> the rest of the FLOSS ecosystem that even having one mode that
> implements some sort of l10n would be huge. Although, it would be nice
> to have that work nicely with already existing l10n processes.

These are orthogonal issues. You can do l10n without modifying syntax.
The export framework already does that, and I gave a POC to handle this
in Emacs.

I have no solution outside of Emacs.

Regards,

-- 
Nicolas Goaziou

Re: Localized org-mode

[Jean-Christophe Helary]

[-- Attachment #1: Type: text/plain, Size: 654 bytes --]

You misquoted me. I was talking about design constraints when C and Lisp were created, which kept language creators from "inventing" proper language localization. I was specifically replying to Diego Zamboni regarding that.

> On May 9, 2018, at 22:25, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
> 
> Hello,
> 
> Jean-Christophe Helary <brandelune@gmail.com> writes:
> 
>> There are no practical reasons why that should not be possible.
> 
> Yet, I gave some already. Consider the following three documents:


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune



[-- Attachment #2: Type: text/html, Size: 2268 bytes --]

Re: Localized org-mode

[Diego Zamboni]

[-- Attachment #1: Type: text/plain, Size: 1439 bytes --]

On Wed, May 9, 2018 at 3:48 PM, Jean-Christophe Helary <brandelune@gmail.com
> wrote:

> You misquoted me. I was talking about design constraints when C and Lisp
> were created, which kept language creators from "inventing" proper language
> localization. I was specifically replying to Diego Zamboni regarding that.
>

I don't think it was only those constraints. Imagine if C and LISP had been
designed with "keywords in your own language" in mind. I'm pretty surre
that would have largely impeded the proliferation of compilers/interpreters
that made possible the explosion of those, and many other, languages.

I fully agree with Nicolas that in this context, localization should be a
display problem and not involve modifying the source. Take for example the
educational language Scratch (https://scratch.mit.edu/), in which you can
localize the language (i.e. the blocks with which you build your programs).
However, if you download the source for your program (it's a JSON file),
it's always the same, no matter in which language you have the interface.

As a first step, you can already configure Emacs so that the markup is
minimally visible. Look at this screenshot, for example:
http://zzamboni.org/post/beautifying-org-mode-in-emacs/emacs-init-propfonts.png.
Most of the formatting is visually communicated, you can only see a few
keywords (properties, begin_src, etc.). It really is very non-intrusive in
my opinion.

--Diego

[-- Attachment #2: Type: text/html, Size: 2211 bytes --]

Re: Localized org-mode

[Jean-Christophe Helary]

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]



> On May 10, 2018, at 0:41, Diego Zamboni <diego@zzamboni.org> wrote:
> 
> 
> On Wed, May 9, 2018 at 3:48 PM, Jean-Christophe Helary <brandelune@gmail.com <mailto:brandelune@gmail.com>> wrote:
> You misquoted me. I was talking about design constraints when C and Lisp were created, which kept language creators from "inventing" proper language localization. I was specifically replying to Diego Zamboni regarding that.
> 
> I don't think it was only those constraints. Imagine if C and LISP had been designed with "keywords in your own language" in mind.

That was not physically possible at the time. It is now. And as I wrote, Scheme can do that easily. But that's not the topic of the current thread. Sorry for that.

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune



[-- Attachment #2: Type: text/html, Size: 2732 bytes --]

Re: Localized org-mode

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

Hello,

On Wed, May 9, 2018 at 8:44 AM Jean-Christophe Helary <brandelune@gmail.com>
wrote:

>
> Genuine question: how many 3rd party tools do support the org format ?
>

Few that I know:

- Orgzly app on Android
- Beorg app on iOS
- Org parser used on Github: https://github.com/wallyqs/org-ruby
<https://github.com/bdewey/org-ruby>
- Org parser in Node.js: https://github.com/daitangio/org-mode-parser
- Another Org parser in JS: https://github.com/mooz/org-js
- .. in Clojure: https://github.com/gmorpheme/organum
- .. in Go: https://github.com/chaseadamsio/goorgeous
- . in Java: https://github.com/orgzly/org-java
- Python-based Org parser to generate blog:
https://github.com/novoid/lazyblorg
- many more:
https://github.com/search?utf8=%E2%9C%93&q=org+mode+parser&type=
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1872 bytes --]

Re: Localized org-mode

[Göktuğ Kayaalp]

On 2018-05-09 21:43 +09, Jean-Christophe Helary <brandelune@gmail.com> wrote:
>> On May 9, 2018, at 21:07, Kaushal Modi <kaushal.modi@gmail.com> wrote:
>> On Wed, May 9, 2018, 8:01 AM Diego Zamboni <diego@zzamboni.org
>> <mailto:diego@zzamboni.org>> wrote:
>> I really don't see the point of trying to localize org keywords. To
>> me, they are like the keywords in any programming language - part of
>> the language. Would you consider translating C or LISP keywords?
>
> There are no practical reasons why that should not be possible. The
> current state of affairs is only due to design constraints when the
> languages were conceived.
>
> In Scheme, for ex. you can actually redefine all the language keywords
> very easily without any impact on the interpreter.

Practical reason: communication.  I'm a Turkish speaker, suppose I'm
monolingual, and I have a problem with the function
‘güncel-devamla-çağır’ in Scheme.  I'd find a fraction of the results if
I was searching for ‘call-with-current-continuation’.  As the small
community of programmers (and the even smaller community of Emacsers
(and as the smaller community of the Org-mode-ers/some-proglang-users
(and as the even smaller community of Org-mode/some-proglang-users users
of some X language as the mother tongue))), we need to communicate, and
we need as much information at our disposal as possible.

The language of programming is English.  I'm completely fine with it.
Being a programmer and not knowing any English has so many disadvantages
that learning it is worthwhile regardless of how much time you've put
into it.  The language of the computers is English too.  Most often,
most software is written in English (even by many non-native speakers)
and maybe translated after the fact, where most of the time (if not all)
the results are sub-par or at most 8/10 (maybe because many terms are
invented in English and require inventing words in other languages which
always sound off).

Furthermore, in the context of this thread, Org allows drawers with
arbitrary names to be defined (e.g. I have :remotes:\n...\n:end: or
:NEXT:\n...\n:END: in a file), with a couple names like :PROPERTIES: and
:LOGBOOK: reserved.  This means that you can't reliably know if anybody
has :PROPRIÉTÉS: or :PROPRIETÀ:, which renders translations impossible.
Same thing with todo keywords, tags, etc.

>> In addition to the trouble of supporting something like this within
>> Emacs, think of the growing ecosystem of tools which support org
>> mode - they would all need to be aware of these localizations. It
>> would be a nightmare to maintain.
>
> Localization, when properly done is never a nightmare to maintain.

I appreciate your efforts on i18n and l10n on Emacs, but unfortunately I
am yet to find a properly localised piece of software, especially in the
FOSS community.  Also, when I need help online, I need the English
messages anyways (and translated manuals, if they ever exist, are a joke
all the time).


-- 
İ. Göktuğ Kayaalp	<https://www.gkayaalp.com/>
			 024C 30DD 597D 142B 49AC
			 40EB 465C D949 B101 2427

Re: Localized org-mode

[Jean-Christophe Helary]

[-- Attachment #1: Type: text/plain, Size: 2750 bytes --]



> On May 12, 2018, at 7:23, Göktuğ Kayaalp <self@gkayaalp.com> wrote:
> 
>>> I really don't see the point of trying to localize org keywords. To
>>> me, they are like the keywords in any programming language - part of
>>> the language. Would you consider translating C or LISP keywords?
>> 
>> There are no practical reasons why that should not be possible. The
>> current state of affairs is only due to design constraints when the
>> languages were conceived.
>> 
>> In Scheme, for ex. you can actually redefine all the language keywords
>> very easily without any impact on the interpreter.
> 
> Practical reason: communication.  I'm a Turkish speaker, suppose I'm
> monolingual, and I have a problem with the function
> ‘güncel-devamla-çağır’ in Scheme.

If you have a problem with that function and you use Scheme, you know that it is mapped to call-with-current-continuation and you know where to look for information. And if you're monolingual, chances are that you won't be able to make sense of what you find in English.

> The language of programming is English.

And of course, when 2 Turkish programmers talk about programming they shift to English... No, they don't. Keywords are arbitrary strings. Try APL and see how "English" applies.

> Org allows drawers with
> arbitrary names to be defined (e.g. I have :remotes:\n...\n:end: or
> :NEXT:\n...\n:END: in a file), with a couple names like :PROPERTIES: and
> :LOGBOOK: reserved.  This means that you can't reliably know if anybody
> has :PROPRIÉTÉS: or :PROPRIETÀ:, which renders translations impossible.
> Same thing with todo keywords, tags, etc.

And that is a good thing.

>> Localization, when properly done is never a nightmare to maintain.
> 
> I appreciate your efforts on i18n and l10n on Emacs, but unfortunately I
> am yet to find a properly localised piece of software, especially in the
> FOSS community.

Proprietary software has so many issues that most pro-grade software is not even localized.

>  Also, when I need help online, I need the English
> messages anyways (and translated manuals, if they ever exist, are a joke
> all the time).

If FOSS activists took as much time fixing manuals as they take for fixing code that would not be an issue. l10n is not as good as code *because* it is not defined with a higher priority and a better consciousness of the linguistic issues, and that is because monolingual activists think one language is sufficient (funny how that does not apply to programming languages, but they don't seem to be conscious of that contradiction...)


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune



[-- Attachment #2: Type: text/html, Size: 5164 bytes --]

Re: Localized org-mode

[Göktuğ Kayaalp]

On 2018-05-12 09:29 +09, Jean-Christophe Helary <brandelune@gmail.com> wrote:
>> On May 12, 2018, at 7:23, Göktuğ Kayaalp <self@gkayaalp.com> wrote:
>>> In Scheme, for ex. you can actually redefine all the language keywords
>>> very easily without any impact on the interpreter.
>> 
>> Practical reason: communication.  I'm a Turkish speaker, suppose I'm
>> monolingual, and I have a problem with the function
>> ‘güncel-devamla-çağır’ in Scheme.
>
> If you have a problem with that function and you use Scheme, you know
> that it is mapped to call-with-current-continuation and you know where
> to look for information. And if you're monolingual, chances are that
> you won't be able to make sense of what you find in English.

How do you know that if you first learned the translated version?  What
do you do if in such a situation you have a long stack trace?  Translate
it before debugging?  Well, in lisp that can be automatic, but even then
I bet it will be popular.  The wikipedia page ‘Non-English-based
programming languages’ is not empty.  And nobody got out of their way to
localise existing languages that allow that to be done easily is telling
(Lisp, Perl).

>> The language of programming is English.
>
> And of course, when 2 Turkish programmers talk about programming they
> shift to English... No, they don't. Keywords are arbitrary
> strings. Try APL and see how "English" applies.

We do, actually, kind of.  We probably use more English words than
Turkish words in that context.

>>  Also, when I need help online, I need the English
>> messages anyways (and translated manuals, if they ever exist, are a joke
>> all the time).
>
> If FOSS activists took as much time fixing manuals as they take for
> fixing code that would not be an issue. l10n is not as good as code
> *because* it is not defined with a higher priority and a better
> consciousness of the linguistic issues, and that is because
> monolingual activists think one language is sufficient (funny how that
> does not apply to programming languages, but they don't seem to be
> conscious of that contradiction...)

There are no «monolingual activists», but just people using the best
available thing.  I myself speak two languages apart form my native
Turkish, learning a third, can read a couple others, and have the desire
to learn more; so I'm no monolingual.  Thing with programming languages
is that them being in one natural language or another does not mean
much; but one programming language may have some features that the other
does not.  And manuals are already insufficent in English itself (very
few projects with good docs exist, one of which is luckily Emacs), let
aside translations.

I guess we're quite off-topic here.

All the best,

-- 
İ. Göktuğ Kayaalp	<https://www.gkayaalp.com/>
			 024C 30DD 597D 142B 49AC
			 40EB 465C D949 B101 2427

Re: Localized org-mode

[Jean-Christophe Helary]

[-- Attachment #1: Type: text/plain, Size: 369 bytes --]



> On May 12, 2018, at 20:07, Göktuğ Kayaalp <self@gkayaalp.com> wrote:

> How do you know that if you first learned the translated version?

Because (define eklemek +)

If you run Scheme, you either know or can discover that.


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune



[-- Attachment #2: Type: text/html, Size: 1922 bytes --]

Re: Localized org-mode

[ST]

> Furthermore, in the context of this thread, Org allows drawers with
> arbitrary names to be defined (e.g. I have :remotes:\n...\n:end: or
> :NEXT:\n...\n:END: in a file), with a couple names like :PROPERTIES: and
> :LOGBOOK: reserved.  This means that you can't reliably know if anybody
> has :PROPRIÉTÉS: or :PROPRIETÀ:, which renders translations impossible.
> Same thing with todo keywords, tags, etc.

1. What about #+TITLE, #+DATE or #+AUTHOR ? What's problem to translate
those?

2. In order to determine reliably what is the language of a particular
document we can introduce #+LANGUAGE which would be English by default.
Others will write #+SPRACHE: Deutsch and then you can use predefined
default mapping of keywords or the local one (overloaded by user) if it
exists in his .emacs.d/org-de-vocabulary.

3. I also prefer English in all my UIs and, for sure, in programming
languages as you, but here I talk about org not as a programming
language but as a _document markup_. Documents that are meant to be
_read as raw source_. There it disturbs, especially if it is a not Latin
letters based language.

Re: Localized org-mode

[Göktuğ Kayaalp]

On 2018-05-12 22:24 +03, ST <smntov@gmail.com> wrote:
>> Furthermore, in the context of this thread, Org allows drawers with
>> arbitrary names to be defined (e.g. I have :remotes:\n...\n:end: or
>> :NEXT:\n...\n:END: in a file), with a couple names like :PROPERTIES: and
>> :LOGBOOK: reserved.  This means that you can't reliably know if anybody
>> has :PROPRIÉTÉS: or :PROPRIETÀ:, which renders translations impossible.
>> Same thing with todo keywords, tags, etc.
>
> 1. What about #+TITLE, #+DATE or #+AUTHOR ? What's problem to translate
> those?

People/packages can define their own keywords for in buffer settings,
and again here translations can cause breakage.

-- 
İ. Göktuğ Kayaalp	<https://www.gkayaalp.com/>
			 024C 30DD 597D 142B 49AC
			 40EB 465C D949 B101 2427

Re: Localized org-mode

[Jean-Christophe Helary]

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]



> On May 13, 2018, at 7:48, Göktuğ Kayaalp <self@gkayaalp.com> wrote:
> 
> People/packages can define their own keywords for in buffer settings,
> and again here translations can cause breakage.

That's a design problem, not a l10n problem.

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune



[-- Attachment #2: Type: text/html, Size: 3285 bytes --]

Re: Localized org-mode

[ST]

On Wed, 2018-05-09 at 13:36 +0200, Diego Zamboni wrote:
> I really don't see the point of trying to localize org keywords. To
> me, they are like the keywords in any programming language - part of
> the language. Would you consider translating C or LISP keywords?

I see org, first of all, as an excellent lightweight markup syntax for
creating documents and not as a programming language, i.e. it should be
readable in raw plain text. Thus it would be more elegant to have native
keywords. Just an idea...

> 
> On Wed, May 9, 2018 at 10:19 AM, Nicolas Goaziou
> <mail@nicolasgoaziou.fr> wrote:
>         Hello,
>         
>         ST <smntov@gmail.com> writes:
>         
>         > So how do you solve this problem now for English
>         ":PROPERTIES:"?
>         
>         Simple. Org does not replace anything arbitrarily. This is
>         less
>         error-prone.
>         
>         > Anyway if somebody runs into it he could have at least to
>         options:
>         >
>         > 1. write local .emacs.d/.org-de-vocabulary which will
>         override the
>         > default one (or parts of it) with a synonym, like:
>         > PROPERTIES -> ATTRIBUTEN
>         > or
>         > PROPERTIES -> ORG_EIGENSCHAFTEN
>         > and then you can replace blindly before parsing.
>         
>         Again, I'm not particularly fond of having conditional syntax
>         like this.
>         
>         > I don't know lisp :(
>         
>         You may want to look at `org-display-custom-time'.
>         
>         Basically, you search for the regexp "^[ \t]*:\\(PROPERTIES\
>         \):", and
>         use `put-text-property' to change the text between
>         (match-beginning 1)
>         and (match-end 1), e.g.,
>         
>             (defun my-properties-translate ()
>               (org-with-point-at 1
>                 (while (re-search-forward "^[ \t]*:\\(PROPERTIES\\):"
>         nil t)
>                   (put-text-property (match-beginning 1) (match-end 1)
>         'display "ATTRIBUTEN"))))
>         
>         You need to add this function to, e.g. `org-mode-hook'. Of
>         course this
>         is really basic and can be improved.
>         
>         Regards,
>         

Re: Localized org-mode

[Rasmus]

> is there something like localized/internationalized org? I.e. all
> keywords, like :PROPERTIES: are translated to another language,
> like :EIGENSCHAFTEN: (for German) so it looks more natural in a foreign
> language. It is of a special importance for languages with non-latin
> letters, where the mix of different languages might be
> visually/esthetically disturbing and require switching of keyboard
> layouts while writing. Technically it should be a simple 1-to-1
> substitution based on an org_keyword_vocabulary for a specific language.

There’s a somewhat popular program called "microsoft excel" that I
sometimes have the misfortune of being exposed to.  It has played with the
idea that you propose.  Function names depends on the LOCALE.  How do you
find the mean of a vector, say?  Well, it depends on the LOCALE of the
system.  My experience is that the result is not pleasant!

Localization should at most (if at all) be supported via with overlays as
others have pointed out, but it would be weird when inserting
e.g. properties (C-c C-x p).

Rasmus

-- 
Need more coffee. . .