...still thinking out loud, I think it would be easier to give someone a file to translate (perhaps?) if the idiom followed something along these lines: .. translate:: "some string"
and .. translate:: %lang%/chapter1.rst for translated rst files The advantage would be to have one place where %lang%_strings.rst, and the various other files (e.g. chapter1.rst) existed. Simultaneous translation efforts of a work (at least) would not need to be merged then. I think the only work would be (in the second case) to do %lang% substitution before a simple include directive, and a Python dictionary lookup on a file named by convention in the first case. I wonder how terrible the lookups could get, and (to keep consistent w/ behavior of other directives) how to manage paragraph translations, such as: .. translate:: * a list * of items ... still thinking... On Thu, Nov 20, 2008 at 5:25 AM, Christophe de VIENNE <[EMAIL PROTECTED]>wrote: > > Hi, > > 2008/11/17 Yarko Tymciurak <[EMAIL PROTECTED]>: > > I am thinking out loud here: > > This is an interesting question. > > I can imagine for some types of text (i.e. instructions) it would be > easier > > to keep consistent is the various language versions were in the same > file, > > output by selector (so the .rst files themselves become self-contained > > translation files), and for other situations (where concepts are more > > important) that context be coherently developed in one language. I > wonder > > if having the former structure (language conditional selector) could be > the > > useful base - and larger context sections be included from files, e.g. > > something that looks like: > > -------------------------------- > > .. lang:: en > > Contents > > .. lang:: fr > > Contenu > > .. lang:: it > > Soddisfare > > > > .. include:: chapter1.%lang%.rst > > or perhaps > > .. include:: %lang$/chapter1.rst > > ------------------------------------ > > The form I've written might be wrong - I mainly want to get the concept > > accross .... at the top of the file, or at build time, some language (or > > lang) setting would be made... > > Ideally we would have a "languages" variable in conf.py, along with a > default_language. > If such options are used, the builders would be run one time for each > language and the language code appended to the output directory name. > > > I wonder if this wouldn't be useful and flexible idiom for authors? > > It think it looks great. That would be perfect for my needs > > > Reasonable to implement? > > I have no idea. If it is, I would be happy to give a hand. > > > Regards, > > Yarko > > > > > > On Mon, Nov 17, 2008 at 5:27 AM, Christophe de VIENNE < > [EMAIL PROTECTED]> > > wrote: > >> > >> Hi, > >> > >> I will need to maintain my documentation in french and in english. I > >> would like to know if some of you do such a thing, and how to you > >> proceed ? > >> My idea is to have two different roots, en and fr which are totally > >> independent. I wonder if there is anything in sphinx to make this > >> easier. > >> > >> Especially for the autodoc extension : It would be great if I could > >> have both versions as docstrings with a directive to tell sphinx the > >> language of the text. > >> > >> Thanks for any hint on this issue, > >> > >> Christophe > >> > >> > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sphinx-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sphinx-dev?hl=en -~----------~----~----~----~------~----~------~--~---
