Multi-language API #59

Closed
duxtinto opened this Issue Mar 19, 2012 · 9 comments

Comments

Projects
None yet
3 participants

Hi everybody!!!

The API is great, but as 90% of my users are spanish, it would be perfect if you could set the language of the html response into the request options (I don´t know if this is the right way to do it, or I should create my own html code from the json response).

If you need some help with the translation, just let me know. ok?

Regards,

David.

Member

jonathantneal commented Mar 20, 2012

Absolutely. We should start working towards something with language files. I'm so pleased we've reached this point!

Owner

drublic commented Mar 28, 2012

Any ideas on how to do this properly?

We could add a GET-flag named "locale" or something and server the data accordingly. But this means we have to have the content translated which seems to be some work to do.
Or we serve the data with templating variables like {{features}}.

we serve the data with templating variables like {{features}}

it means that any string on the response will be a variable, and my
javascript code is in charge of replace them with my own translated
strings. isn't it?

I think is a good idea, because you dont need to worry about translating
strings (now and after any change you'll do to the service in the future)
but it makes the service less friendly to the developer (it's much more
friendly to use the locale get-flag, and forget it about any translation...
and it's even helpful if you have your website translated into several
languages)

We could add a GET-flag named "locale" or something and server the data

accordingly.

At the other hand, using the GET-param implies that you need to get a
community of people translating the strings (now and in the future), and in
case of the website is in a language that you don't support, it's less
flexible than the other solution (I suppose the server will response with
the original English version. isn't it?)

In summary, and talking from an outsider's point of view (maybe I'm going
to say some stupid things :)), I think, at the beginning, the 'templating
variables' solution will be the most flexible and not-paintful.
Later, if you get enough people involved with the translations (I can help
you translating the strings to Spanish), you could add the 'Get-flag named
'locale' to make everybody's life easier, without losting flexibility.

What do you think?

On Wed, Mar 28, 2012 at 5:42 PM, Hans <
reply@reply.github.com

wrote:

Any ideas on how to do this properly?

We could add a GET-flag named "locale" or something and server the data
accordingly. But this means we have to have the content translated which
seems to be some work to do.
Or we serve the data with templating variables like {{features}}.


Reply to this email directly or view it on GitHub:
#59 (comment)

Owner

drublic commented Mar 28, 2012

David, thanks for your comments!

I don't think we will drop out the default english version. The new param will be part of the request string:
[…]querySelector.json?callback=h5p&texticon&html&readable__&locale__ or &template

This could serve a version with templating-variables to use with Mustache or something. Defining any text would be left to the user. This means full flexibility for developers.

Translation, as I said before, seems to be a lot of work.

David, thanks for your comments!

You are welcome!!

This could serve a version with templating-variables to use with
Mustache or something. Defining any text
would be left to the user. This means full flexibility for developers.

ok. I see.
This solution looks very good to me.

On Wed, Mar 28, 2012 at 11:10 PM, Hans <
reply@reply.github.com

wrote:

David, thanks for your comments!

I don't think we will drop out the default english version. The new param
will be part of the request string:
[]querySelector.json?callback=h5p&texticon&html&readable__&locale__ or
&template

This could serve a version with templating-variables to use with
Mustache or something. Defining any text
would be left to the user. This means full flexibility for developers.

Translation, as I said before, seems to be a lot of work.


Reply to this email directly or view it on GitHub:
#59 (comment)

Owner

drublic commented Apr 4, 2012

I've wrapped my head around it and added another branch to my fork.
I have implemented a template which uses Mustache-like variables. You get the local-oriented version with an extra parameter called notemplate when requesting the JSON. On the page I've added a new option for this.

Take a look at it if you want to. I'll merge this and add some documentation about it soon-ish.
As always: feedback appreciated.

Owner

drublic commented Apr 8, 2012

I've pushed my work into the master. The option is not yet visible on the page, as I want to wait for some feedback on this.
Here is a short documentation on the templating variables. More to come…

Looks ok?

It looks quite good to me...

one small thing... I don´t know if I missed something (quite probably :)) but the name of the option 'noTemplate' sounds a little bit confusing to me... before checking the documentation, my first guess was 'noTemplate' => not using the template, so getting the english version.

Regards.

Owner

drublic commented Apr 15, 2012

Yeah, had the same problems after developing it. I've changed it now to "template" which seems more appropriate.
Furthermore the option for it is now visible on the page (at least in the master-branch – will be online soon I guess).

drublic closed this Apr 15, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment