support for i18n (lang var) in asciidoctor*

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

support for i18n (lang var) in asciidoctor*

ciampix
Hello people,
for a multilanguage project, I would like to do something like:

a2x -a lang=xx ...

where xx is en (or nothing like it is the default), fr, de, it, jp, ru ...

like I used to do with the asciidoc suite but with:

asciidoctor
asciidoctor-pdf
asciidoctor-epub3

any hint?

--

Saluton,
Marco Ciampa
Reply | Threaded
Open this post in threaded view
|

Re: support for i18n (lang var) in asciidoctor*

mojavelinux
Administrator
What you may be looking for is described here: https://docs.asciidoctor.org/asciidoctor/latest/localization-support/

That's the extent to which the processor supports localization. The processor does not attempt to manage translation of the content itself.

Best Regards,

-Dan

On Sat, Feb 20, 2021 at 3:03 AM ciampix [via Asciidoctor :: Discussion] <[hidden email]> wrote:
Hello people,
for a multilanguage project, I would like to do something like:

a2x -a lang=xx ...

where xx is en (or nothing like it is the default), fr, de, it, jp, ru ...

like I used to do with the asciidoc suite but with:

asciidoctor
asciidoctor-pdf
asciidoctor-epub3

any hint?

--

Saluton,
Marco Ciampa



If you reply to this email, your message will be added to the discussion below:
https://discuss.asciidoctor.org/support-for-i18n-lang-var-in-asciidoctor-tp8521.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML


--
Dan Allen (he, him, his) | @mojavelinux | https://twitter.com/mojavelinux
Reply | Threaded
Open this post in threaded view
|

Re: support for i18n (lang var) in asciidoctor*

ciampix
On Sat, Feb 20, 2021 at 03:06:25AM -0700, mojavelinux [via Asciidoctor :: Discussion] wrote:

>
> What you may be looking for is described here:
> https://docs.asciidoctor.org/asciidoctor/latest/localization-support/
>
> That's the extent to which the processor supports localization. The
> processor does not attempt to manage translation of the content itself.
>
> Best Regards,
>
> -Dan

Wow that fast a fast reply! Thanks!

Ok let me reformulate the question.

In order to mimic the same behaviour, since for what I have seen, simply
adding the -a lang=xx does not actually work, that implies that:

1) I would espect that language definitions for labels were included in
   the asciidoctor* packages. Apparently that is not so actually.
   Why not?

2) since 1) it seems that I have to include language definition for labels
   in my build chain. Where I can download language definition for labels
   of all languages (if there are any, I am sure that somewhere there are
   I ever emember to have sent you my native language strings sometime ago)
   or have I to infer those strings from the old asciidoc language
   definitions (lang-xx.conf)?

TIA

--

Saluton,
Marco Ciampa
Reply | Threaded
Open this post in threaded view
|

Re: support for i18n (lang var) in asciidoctor*

mojavelinux
Administrator
> I would espect that language definitions for labels were included in the asciidoctor* packages. Apparently that is not so actually.

Yes, they are there. You can find them in the data folder.

ls $(dirname $(dirname $(gem which asciidoctor)))/data/locale

If you read the document I linked to fully, you would see that there is a link to this folder in the GitHub repository if you want to download them. There's also a link to an issue about making this behavior automatic. See https://github.com/asciidoctor/asciidoctor/issues/1129

The file is not loaded automatically when you set the lang attribute because it has always been left up to the reader to decide how to handle. The docs explain how to do that. If you can propose a way to do automatically that is backwards compatible, I'm listening. Though it's not something I have time to work on right now.

Best Regards,

-Dan

On Sat, Feb 20, 2021 at 3:21 AM ciampix [via Asciidoctor :: Discussion] <[hidden email]> wrote:
On Sat, Feb 20, 2021 at 03:06:25AM -0700, mojavelinux [via Asciidoctor :: Discussion] wrote:

>
> What you may be looking for is described here:
> https://docs.asciidoctor.org/asciidoctor/latest/localization-support/
>
> That's the extent to which the processor supports localization. The
> processor does not attempt to manage translation of the content itself.
>
> Best Regards,
>
> -Dan
Wow that fast a fast reply! Thanks!

Ok let me reformulate the question.

In order to mimic the same behaviour, since for what I have seen, simply
adding the -a lang=xx does not actually work, that implies that:

1) I would espect that language definitions for labels were included in
   the asciidoctor* packages. Apparently that is not so actually.
   Why not?

2) since 1) it seems that I have to include language definition for labels
   in my build chain. Where I can download language definition for labels
   of all languages (if there are any, I am sure that somewhere there are
   I ever emember to have sent you my native language strings sometime ago)
   or have I to infer those strings from the old asciidoc language
   definitions (lang-xx.conf)?

TIA

--

Saluton,
Marco Ciampa



If you reply to this email, your message will be added to the discussion below:
https://discuss.asciidoctor.org/support-for-i18n-lang-var-in-asciidoctor-tp8521p8523.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML


--
Dan Allen (he, him, his) | @mojavelinux | https://twitter.com/mojavelinux
Reply | Threaded
Open this post in threaded view
|

Re: support for i18n (lang var) in asciidoctor*

ciampix
On Sat, Feb 20, 2021 at 05:54:46AM -0700, mojavelinux [via Asciidoctor :: Discussion] wrote:
>
> > I would espect that language definitions for labels were included in the
> asciidoctor* packages. Apparently that is not so actually.
>
> Yes, they are there. You can find them in the data folder.
>
> ls $(dirname $(dirname $(gem which asciidoctor)))/data/locale

oh yes you are right! (and BTW interesting line of scritpt!)

> If you read the document I linked to fully, you would see that there is a
> link to this folder in the GitHub repository if you want to download them.
> There's also a link to an issue about making this behavior automatic. See
> https://github.com/asciidoctor/asciidoctor/issues/1129

interesting, so it's still an open issue ...

> The file is not loaded automatically when you set the lang attribute
> because it has always been left up to the reader to decide how to handle.
> The docs explain how to do that. If you can propose a way to do
> automatically that is backwards compatible, I'm listening. Though it's not
> something I have time to work on right now.

As always, Dan, you are very helpful... I will figure out a way to handle
this in the hope you'll find a way to handle this properly and in a
backward compatible way...

--

Saluton,
Marco Ciampa
Reply | Threaded
Open this post in threaded view
|

Re: support for i18n (lang var) in asciidoctor*

mojavelinux
Administrator
On Sat, Feb 20, 2021 at 8:44 AM ciampix [via Asciidoctor :: Discussion] <[hidden email]> wrote:
> ls $(dirname $(dirname $(gem which asciidoctor)))/data/locale

oh yes you are right! (and BTW interesting line of scritpt!)

Here's a slightly more concise way to access that path:

ls $(dirname $(gem which asciidoctor))/../data/locale

Here's how to access it with pure Ruby:

ruby -r asciidoctor -e "puts File.join Gem.loaded_specs['asciidoctor'].gem_dir, 'data/locale'"


> There's also a link to an issue about making this behavior automatic. See
> https://github.com/asciidoctor/asciidoctor/issues/1129

interesting, so it's still an open issue ...

It's an open idea. There hasn't been a decision made about whether this should be supported or how.
 
As always, Dan, you are very helpful...

Always glad to help out!
 
in the hope you'll find a way to handle this properly and in a backward compatible way...

If the community wants this to work differently, then someone in the community needs to bring forward a proposal. As I said, it's not something I will be trying to figure out on my own.

Best Regards,

-Dan