Discussion:
[O] Localized org-mode
Jean-Christophe Helary
2018-05-12 00:29:41 UTC
Permalink
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
Jean-Christophe Helary
2018-05-12 23:48:32 UTC
Permalink
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
Jean-Christophe Helary
2018-05-12 11:58:43 UTC
Permalink
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
Jean-Christophe Helary
2018-05-09 23:36:43 UTC
Permalink
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
Kaushal Modi
2018-05-09 20:28:00 UTC
Permalink
Hello,
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
Continue reading on narkive:
Loading...