Re: [O] [RFC] Introduce ox-i18n.el

2013-07-02 Thread Jambunathan K
Nicolas Goaziou n.goaz...@gmail.com writes:

 +(defconst org-export-dictionary



Why?  



Re: [O] [RFC] Introduce ox-i18n.el

2013-07-02 Thread Rasmus
Nicolas Goaziou n.goaz...@gmail.com writes:

 I would like to move every variable and function related to
 internationalization (i.e smart quotes and translations) in a dedicated
 file (ox-i18n.el) instead of ox.el.

 Considering ox.el is 6k lines long, I think it can be a bit tedious to
 locate and modify internationalization entries. And since we are missing
 quite a few translations, every little bit can help.

So I did some translation work today, and I now support this notion
further.  It's super tedious /finding/ all the correct variables, as
they are not spread all over the place.

Should the ox-latex language-code to babel list also be included in an
ox-int'l file?  The reason is that I found some bugs in this list
and perhaps further language related bugs would be easier to detect if
they were in the same file.

-- 
Don't panic!!!




Re: [O] [RFC] Introduce ox-i18n.el

2013-07-02 Thread Nicolas Goaziou
Hello,

Jambunathan K kjambunat...@gmail.com writes:

 Nicolas Goaziou n.goaz...@gmail.com writes:

 +(defconst org-export-dictionary
 
 

 Why?

Because it is not meant to be changed by the user nor let-bound. IOW,
it's a constant.


Regards,

-- 
Nicolas Goaziou



Re: [O] [RFC] Introduce ox-i18n.el

2013-07-02 Thread Rasmus

Hello,

 +(defconst org-export-dictionary
 
 

 Why?

 Because it is not meant to be changed by the user nor let-bound. IOW,
 it's a constant.

But perhaps it should not be.  Consider org-export-smart-quotes-alist.
In Danish, according to the 'official' guidance, all of the following
are appropriate

(*)   ,,.'', ``.'', `.', ., ..

Basically, only the french . is not appropriate.  A similar
situation exists in Norwegian, to the best of my knowledge.  Why
should I (submitting a patch) be able to actively force which of forms
in (*) should be used?

One remedy /in LaTeX/ would be to let quote-characters be selected by
csquote, but I don't really know if I'd want to go that way. . .

Alternatively, we can populate the various language variables and
provide easy means to alter them, a la:

  (org-alter-language da :left-latex `` :right-latex '' :table tabel).

–Rasmus

-- 
⠠⠵




Re: [O] [RFC] Introduce ox-i18n.el

2013-07-02 Thread Nicolas Goaziou
Hello,

Rasmus ras...@gmx.us writes:

 Should the ox-latex language-code to babel list also be included in an
 ox-int'l file?  The reason is that I found some bugs in this list
 and perhaps further language related bugs would be easier to detect if
 they were in the same file.

I don't think so. Bugs in happening in latex export only are expected to
be found in ox-latex.


Regards,

-- 
Nicolas Goaziou



Re: [O] [RFC] Introduce ox-i18n.el

2013-07-02 Thread Jambunathan K
Nicolas Goaziou n.goaz...@gmail.com writes:

 Hello,

 Jambunathan K kjambunat...@gmail.com writes:

 Nicolas Goaziou n.goaz...@gmail.com writes:

 +(defconst org-export-dictionary
 
 

 Why?

 Because it is not meant to be changed by the user nor let-bound. IOW,
 it's a constant.

Lately, users ARE modifying it.



 Regards,



Re: [O] [RFC] Introduce ox-i18n.el

2013-07-02 Thread Jambunathan K
Nicolas Goaziou n.goaz...@gmail.com writes:

 Even though it is a defconst, you can still change it. You are not
 forced to anything. But you're on your own.

 By the way, it is a defconst because of the keys, which shouldn't be
 altered, not the values.

It /may/ be converted to a defcustom.  Lots of people seem interested in
modifying it.

Btw, HTML provides q /q for generating quotes.  This is what the
Creole markup engine for Oddmuse is using.  Apparently, the quotes
that gets emitted can be controlled on per-language basis through some
CSS.





Re: [O] [RFC] Introduce ox-i18n.el

2013-07-02 Thread Nicolas Goaziou
Jambunathan K kjambunat...@gmail.com writes:

 Nicolas Goaziou n.goaz...@gmail.com writes:

 Even though it is a defconst, you can still change it. You are not
 forced to anything. But you're on your own.

 By the way, it is a defconst because of the keys, which shouldn't be
 altered, not the values.

 It /may/ be converted to a defcustom.  Lots of people seem interested in
 modifying it.

Of course. Patch welcome.


Regards,

-- 
Nicolas Goaziou



Re: [O] [RFC] Introduce ox-i18n.el

2013-07-02 Thread Jambunathan K
Nicolas Goaziou n.goaz...@gmail.com writes:

 Of course. Patch welcome.

The conversation is taking a humorous turn.



Re: [O] [RFC] Introduce ox-i18n.el

2013-07-02 Thread Rasmus
Nicolas Goaziou n.goaz...@gmail.com writes:

 Even though it is a defconst, you can still change it. You are not
 forced to anything. But you're on your own.

I agree, but it being a defconst, it comes with the message

  This declares that neither programs nor users should ever change
   the value.

 By the way, it is a defconst because of the keys, which shouldn't be
 altered, not the values. 

If that's really a the concern then why not write a function to alter
values in a safe manner?

Alternatively, it could stay defconst, and there could be a
org-export-smart-quotes-alist-user, defaulting to nil but taking
precedence over its non-user counterpart.  If people specify a wrong
language code it'll just be ignored.

–Rasmus

-- 
When in doubt, do it!




Re: [O] [RFC] Introduce ox-i18n.el

2013-07-02 Thread Jambunathan K
Rasmus ras...@gmx.us writes:

 Nicolas Goaziou n.goaz...@gmail.com writes:

 Even though it is a defconst, you can still change it. You are not
 forced to anything. But you're on your own.

 I agree, but it being a defconst, it comes with the message

   This declares that neither programs nor users should ever change
the value.

 By the way, it is a defconst because of the keys, which shouldn't be
 altered, not the values. 

 If that's really a the concern then why not write a function to alter
 values in a safe manner?

 Alternatively, it could stay defconst, and there could be a
 org-export-smart-quotes-alist-user, defaulting to nil but taking
 precedence over its non-user counterpart.  If people specify a wrong
 language code it'll just be ignored.

Snippet below is a good starting point, for customizability you are
asking for.

(defcustom ox-sq-alist  nil
  
  :type '(alist :key-type string :value-type
(alist :key-type symbol
   :options (ODQ CDQ OSQ CSQ)
   :value-type (plist :options (:utf-8 :html :latex 
:texinfo)


 –Rasmus



Re: [O] [RFC] Introduce ox-i18n.el

2013-07-01 Thread Sebastien Vauban
Hello,

Rasmus wrote:
 Nicolas Goaziou n.goaz...@gmail.com writes:

 I would like to move every variable and function related to
 internationalization (i.e smart quotes and translations) in a dedicated
 file (ox-i18n.el) instead of ox.el.

 Sounds good to me.

+1

 How about a more informative name where uninformed need not look up
 the meaning of i18n on Wikipedia? ox-translation(s) or something
 like that. . .

+1 regarding the name i18n. It does not mean much to me. I'd favor
ox-international(ization) or ox-strings or ox-translation(s) or ...

Now, if i18n is some kind of standard, that's good as well. It then means a
lot to people looking for translation strings.

Best regards,
  Seb

-- 
Sebastien Vauban




Re: [O] [RFC] Introduce ox-i18n.el

2013-07-01 Thread Bastien


Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org
writes:

 Sounds good to me.

 +1

Let's clearly think about what problem it is supposed to solve:
if it is just discoverability for potential contributors, I don't
think it's worth the split.

-- 
 Bastien




Re: [O] [RFC] Introduce ox-i18n.el

2013-06-29 Thread Bastien
Hi Nicolas,

Nicolas Goaziou n.goaz...@gmail.com writes:

 I would like to move every variable and function related to
 internationalization (i.e smart quotes and translations) in a dedicated
 file (ox-i18n.el) instead of ox.el.

 Considering ox.el is 6k lines long, I think it can be a bit tedious to
 locate and modify internationalization entries. And since we are missing
 quite a few translations, every little bit can help.

Maybe we can generalize even more, call it org-i18n.el and have
`org-clock-clocktable-language-setup' (and maybe others) included?

If ox-i18n.el exists, it will be confusing to have other i18n
pieces in other part of Org.

If the *only* purpose is to boost translations, I don't think
moving the code the right thing to do: we simply need to give
more pointers on the website on how to help with it.

2 cts,

-- 
 Bastien



Re: [O] [RFC] Introduce ox-i18n.el

2013-06-29 Thread Rasmus
Nicolas Goaziou n.goaz...@gmail.com writes:

 I would like to move every variable and function related to
 internationalization (i.e smart quotes and translations) in a dedicated
 file (ox-i18n.el) instead of ox.el.

Sounds good to me.

How about a more informative name where uninformed need not look up
the meaning of i18n on Wikipedia? ox-translation(s) or something
like that. . .

–Rasmus

-- 
El Rey ha muerto. ¡Larga vida al Rey!