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

Support conditional compile / flavors #40

Open
Swatinem opened this issue Jan 2, 2014 · 7 comments
Open

Support conditional compile / flavors #40

Swatinem opened this issue Jan 2, 2014 · 7 comments
Labels

Comments

@Swatinem
Copy link

Swatinem commented Jan 2, 2014

So what I want to achieve here is something like this:

Lets say you have a translation dictionary in all kinds of different languages ['en', 'de', 'hu', …]

It should be possible to compile

  • every flavor into one build, which would make clientside language switching possible
  • or each flavor in its separate build, so that the server can do language negotiation and just serve the requested lang

It does not need to be limited to languages. It might also be browser support, where we can compile separately one lean version for modern browsers and one fat (+50K) version for IE8 or something.

It might be a little related to #11, but for translations, it does not make sense to split them into separate packages.

@jonathanong
Copy link
Contributor

honestly, i wouldn't include translations into the build. i would actually have separate translation files and include only the one i need as a separate file. shouldn't be difficult with component-bundle or something like it.

this is also why i do my templating server-side :P

@Swatinem
Copy link
Author

Swatinem commented Jan 2, 2014

by separate file you mean a <script>, right?

Well that would be good for local components. But what about published ones, ideally they should include translations, but still be as lightweight as possible by default.
There are a lot of components out there that are pretty useless because they are specific to the english locale and don’t include translation support. See component/relative-date#5, I totally forgot to create a PR for that back when I did it :-D

@Swatinem
Copy link
Author

Swatinem commented Jan 2, 2014

Looking at moment for example, they really go the route of providing the locales as separate files: https://github.com/moment/moment/blob/develop/component.json
However that would conflict with other components doing the same thing.

@jonathanong
Copy link
Contributor

hmmm do you have a suggestion on how to handle it? it would have to be a different property.

if you want to make your own plugin, you can try putting all the translations into a .translations property or something then have a custom builder handle it.

@Swatinem
Copy link
Author

Swatinem commented Jan 2, 2014

Ye, maybe I can try that. But component install also needs to correctly fetch those, similar to componentjs/component@5654ff6, haha

@ianstormtaylor
Copy link
Contributor

this should be possible when we merge @yields's builder pr?

@jonathanong
Copy link
Contributor

i think the question is more whether it should be in the specs (translations, or, generally, optional deps/scripts/styles, etc). someone's going to have to implement it first though so we can judge.

we could just close this for now since this isn't something that would be going in soon

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

No branches or pull requests

3 participants