Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better multi-language support in the build system #710

Open
deontologician opened this issue Apr 14, 2015 · 2 comments
Open

Better multi-language support in the build system #710

deontologician opened this issue Apr 14, 2015 · 2 comments
Milestone

Comments

@deontologician
Copy link
Contributor

Right now we need 3 identical copies of each documentation page, which need to be kept in sync. This is really error prone, and I'm sure super annoying for @chipotle. With the upcoming creation of an official java driver (rethinkdb/rethinkdb#3930) slated for 2.1, the work is about to increase 33%.

Ideally, what it would be really nice to see are some custom tags that we can pre-process into the final files that jekyll uses (if there's some way to make this a jekyll plugin, even better)

Hypothetically:

In the {{#py "python"}}{{#rb "ruby"}}{{#js "javascript"}} driver, we do things like ...

{{#py}}
The python driver uses tornado underneath, so we create generators...
{{/py}}
{{#rb}}
Eventmachine is a wonderful way to do magical delightful ruby things...
{{/rb}}

Having per-language tags as above would be a nice start. Obviously there are some more convenient things we could do, like having a special tag like {{#lang}} that outputs the current language's name, since that will probably be common.

@mglukhovsky @AtnNn thoughts?

@mglukhovsky
Copy link
Member

@deontologician: I think this is a very important discussion to have. I have a lot of ideas on this, but not a lot of time to write them up now, but I'll revisit this as soon as possible.

Your proposal seems reasonable. I'd like to find an example of a document where the multi-language docs diverge significantly, because while I believe that the syntax you're proposing makes complete sense, I'm worried that there are several documents where this syntax would make the source document incredibly complex (especially in the API docs).

@chipotle, do any examples come to mind, or does a syntax like this seem reasonable?

@chipotle
Copy link
Contributor

It seems reasonable. The big caveat is the API docs, as you mentioned -- it would make the source document complex, but at the same time that's where this might be the most helpful, since the API docs are nearly-identical text with language-specific examples. Although I would probably add a {{#cc "camelCase" }} tag or something similar that outputs camelCase or camel_case depending on the language chosen, because doing that in text with a series of conditionals would get very verbose very quickly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants