Pain easy way to have different locale files "admin" vs "frontend"

13 показвания
Преминаване към първото непрочетено съобщение

Fotis Paraskevopoulos

непрочетено,
7.04.2015 г., 9:04:177.04.15 г.
до apostr...@googlegroups.com
Hello Tom,

Is there an easy (pain free) way to have the administration UI (menus, buttons, snippets dialog) etc maintain one language, whilst at the same time be able to define different Languages only for front end site wide stuff?

What is happening now is that we are providing translations for some strings which are being statically outputed in some templates, and we define translations using locales/*.json files. The problem is that if any of those strings are also available in the administration, that too gets translated.

As it stands is a huge headache for us right, so I am wondering if there is any way to hack __() so that we can specify the "context".

Thanks,
Fotis

Tom Boutell

непрочетено,
7.04.2015 г., 9:18:257.04.15 г.
до apostr...@googlegroups.com
You want to switch to "French" and see French, except keep the admin interface in English (for example)?

Right now there is only one __() helper being used in all contexts, so currently the answer is no.

This is probably something that could be contributed in the 0.6/1.0 timeframe.


--
You received this message because you are subscribed to the Google Groups "apostrophenow" group.
To unsubscribe from this group and stop receiving emails from it, send an email to apostropheno...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--


THOMAS BOUTELL, DEV & OPS
P'UNK AVENUE | (215) 755-1330  |  punkave.com

Fotis Paraskevopoulos

непрочетено,
7.04.2015 г., 9:21:007.04.15 г.
до apostr...@googlegroups.com
Ok,

Good news about the 0.6!

What would be the optimal way form me to create lets say ___() ( with three _ ) which extends yours? Remember I am keeping my own apostrophe and apostrophe-pages branch.

Maybe this could lead to a pull request in the future.

Best,
Fotis

Tom Boutell

непрочетено,
7.04.2015 г., 9:22:537.04.15 г.
до apostr...@googlegroups.com
If you want to do it that way you could just shovel it in with apos.addLocal like you would any other helper function.


Fotis Paraskevopoulos

непрочетено,
7.04.2015 г., 9:24:087.04.15 г.
до apostr...@googlegroups.com
Thanks!

Fotis Paraskevopoulos

непрочетено,
8.04.2015 г., 3:15:368.04.15 г.
до Fotis Paraskevopoulos,apostr...@googlegroups.com
Hello All,

This is what I ended up doing in case you need the same


on your app.js, in you afterInit call you do


require('you_module_location')(site);

and you acquire a triple underscore call for your front end locale.

You locale files will be generated under the "frontend-locales" folder.


Best,
Fotis

Tom Boutell

непрочетено,
8.04.2015 г., 7:09:228.04.15 г.
до apostr...@googlegroups.com
Nice, Fotis. However it looks like the i18n module is set up as a singleton, you can't really have two separate instances. You may be "getting away with it" because you "npm installed" it at project level and the apostrophe module already has a private copy, but on a future "npm install" npm is likely to helpfully give you just one shared copy. ):

To be clear, if I'm right this is an issue with the i18n module, not apostrophe. Just wanted to make you aware of it.

You could hack around it by copying the module. A better idea is probably opening a ticket for i18n to support two deliberately separate instances.

Fotis Paraskevopoulos

непрочетено,
8.04.2015 г., 7:19:598.04.15 г.
до apostr...@googlegroups.com
Yes I see,

I was sure that this was the case, but it seemed to work, so I didn't mess with it :).

The ticket sounds like the best course of action.

Best,
Fotis


Отговор до всички
Отговор до автора
Препращане
0 нови съобщения