I'm working with Slim 4 Framework with a Twig engine for templates.
Some time ago, Twig had an extension with {% trans %} tokens and |trans filter directly linked to gettext function.
Now things seems to be more complicated, Twig is linked to a Symfony Translator... do you know how can I link Twig to gettext?
I tried to create a custom filter, and it works, but I don't know how to create a tokenparser just to call gettext() function.
The "official" way would be to use the Twig-Bridge component that provides a Twig 3 TranslationExtension to translate messages with the trans
filter. For this, you have to install the Symfony translator component.
The TranslationExtension can be configured with a custom Translator that must implement the TranslatorInterface. The Symfony Translator is able to use mo files as source. So you don't have to use the gettext extension anymore.
use Symfony\Bridge\Twig\Extension\TranslationExtension;
use Symfony\Component\Translation\Translator;
use Symfony\Component\Translation\Formatter\MessageFormatter;
use Symfony\Component\Translation\IdentityTranslator;
use Symfony\Component\Translation\Loader\MoFileLoader;
use Slim\Views\Twig;
// ...
$twig = Twig::create($paths, $options);
$translator = new Translator(
'en_US',
new MessageFormatter(new IdentityTranslator())
);
$translator->addLoader('mo', new MoFileLoader());
$twig->addExtension(new TranslationExtension($translator));
If you still want to use the gettext function, you could also try to create a custom Twig function:
https://symfony.com/doc/current/templating/twig_extension.html
use Twig\TwigFunction;
$environment = $twig->getEnvironment();
$environment->addFunction(new TwigFunction('__', function ($message) {
return __($message);
}));
Usage
{{ __('Hello world') }}
The downside of the second approach is that you need a custom text parser.
I have solved adding this dependency to composer:
twig/extensions
And this extension to Twig config:
$twig = Twig::create($twigSettings['path'], $twigSettings['settings']);
$twig->addExtension(new I18nExtension());
After spending a few years locked into an ancient tech stack for a project, I'm finally getting a chance to explore more current frameworks and dip a toe into React and Webpack. So far, it's for the most part been a refreshing and enjoyable experience, but I've run across some difficulty with Webpack that I'm hoping the hive-mind can help resolve.
I've been poring over the Webpack 2.0 docs and have searched SO pretty exhaustively, and come up short (I've only turned up this question, which is close, but I'm not sure it applies). This lack of information out there makes me think that I'm looking at one of two scenarios:
What I'm trying to do is insane.
What I'm trying to do is elementary to the point that it should be a no-brainer.
...and yet, here I am.
The short version of what I'm looking for is a way to exclude certain JSX components from being included in the Webpack build/bundle, based on environment variables. At present, regardless of what the dependency tree should look like based on what's being imported from the entry js forward, Webpack appears to be wanting to bundle everything in the project folder.
I kind of assume this is default behavior, because it makes some sense -- an application may need components in states other than the initial state. In this case, though, our 'application' is completely stateless.
To give some background, here are some cursory requirements for the project:
Project contains a bucket of components which can be assembled into a page and given a theme based on a config file.
Each of these components contains its own modular CSS, written in SASS.
Each exported page is static, and the bundle actually gets removed from the export directory. (Yes, React is a bit of overkill if the project ends at simply rendering a series of single, static, pages. A future state of the project will include a UI on top of this for which React should be a pretty good fit, however -- so best to have these components written in JSX now.)
CSS is pulled from the bundle using extract-text-webpack-plugin - no styles are inlined directly on elements in the final export, and this is not a requirement that can change.
As part of the page theme information, SASS variables are set which are then used by the SASS for each of the JSX components.
Only SASS variables for the JSX components referenced in a given page's config file are compiled and passed through sass-loader for use when compiling the CSS.
Here's where things break down:
Let's say I have 5 JSX components, conveniently titled component_1, component_2, component_3, and so on. Each of these has a matching .scss file with which it is associated, included in the following manner:
import React from 'react';
import styles from './styles.scss';
module.exports = React.createClass({
propTypes: {
foo: React.PropTypes.string.isRequired,
},
render: function () {
return (
<section className={`myClass`}>
<Stuff {...props} />
</section>
);
},
});
Now let's say that we have two pages:
page_1 contains component_1 and component_2
page_2 contains component_3, component_4, and component_5
These pages both are built using a common layout component that decides which blocks to use in a manner like this:
return (
<html lang='en'>
<body>
{this.props.components.map((object, i) => {
const Block = component_templates[object.component_name];
return <Block key={i}{...PAGE_DATA.components[i]} />;
})}
</body>
</html>
);
The above iterates through an object containing my required JSX components (for a given page), which is for now created in the following manner:
load_components() {
let component_templates = {};
let get_component = function(component_name) {
return require(`../path/to/components/${component_name}/template.jsx`);
}
for (let i = 0; i < this.included_components.length; i++) {
let component = this.included_components[i];
component_templates[component] = get_component(component);
}
return component_templates;
}
So the general flow is:
Collect a list of included components from the page config.
Create an object that performs a require for each such component, and stores the result using the component name as a key.
Step through this object and include each of these JSX components into the layout.
So, if I just follow the dependency tree, this should all work fine. However, Webpack is attempting to include all of our components, regardless of what the layout is actually loading. Due to the fact that I'm only loading SASS variables for the components that are actually used on a page, this leads to Webpack throwing undefined variable errors when the sass-loader attempts to process the SASS files associated with the unused modules.
Something to note here: The static page renders just fine, and even works in Webpack's dev server... I just get a load of errors and Webpack throws a fit.
My initial thought is that the solution for this is to be found in the configuration for the loader I'm using for the JSX files, and maybe I just needed to tell the loader what not to load, if Webpack was trying to load everything. I'm using `babel-loader for that:
{ test: /\.jsx?$/,
loader: 'babel-loader',
exclude: [
'./path/to/components/component_1/',
],
query: { presets: ['es2015', 'react'] }
},
The exclude entry there is new, and does not appear to work.
So that's kind of a novella, but I wanted to err on the side of too much information, as opposed to being scant. Am I missing something simple, or trying to do something crazy? Both?
How can I get unused components to not be processed by Webpack?
TL;DR
Don't use an expression in require and use multiple entry points, one for each page.
Detailed answer
Webpack appears to be wanting to bundle everything in the project folder.
That is not the case, webpack only includes what you import, which is determined statically. In fact many people that are new to webpack are confused at first that webpack doesn't just include the entire project. But in your case you have hit kind of an edge case. The problem lies in the way you're using require, specifically this function:
let get_component = function(component_name) {
return require(`../path/to/components/${component_name}/template.jsx`);
}
You're trying to import a component based on the argument to the function. How is webpack supposed to know at compile time which components should be included? Well, webpack doesn't do any program flow analysis, and therefore the only possibility is to include all possible components that match the expression.
You're sort of lucky that webpack allows you to do that in the first place, because passing just a variable to require will fail. For example:
function requireExpression(component) {
return require(component);
}
requireExpression('./components/a/template.jsx');
Will give you this warning at compile time even though it is easy to see what component should be required (and later fails at run-time):
Critical dependency: the request of a dependency is an expression
But because webpack doesn't do program flow analysis it doesn't see that, and even if it did, you could potentially use that function anywhere even with user input and that's essentially a lost cause.
For more details see require with expression of the official docs.
Webpack is attempting to include all of our components, regardless of what the layout is actually loading.
Now that you know why webpack requires all the components, it's also important to understand why your idea is not going to work out, and frankly, overly complicated.
If I understood you correctly, you have a multi page application where each page should get a separate bundle, which only contains the necessary components. But what you're really doing is using only the needed components at run-time, so technically you have a bundle with all the pages in it but you're only using one of them, which would be perfectly fine for a single page application (SPA). And somehow you want webpack to know which one you're using, which it could only know by running it, so it definitely can't know that at compile time.
The root of the problem is that you're making a decision at run-time (in the execution of the program), instead this should be done at compile time. The solution is to use multiple entry points as shown in Entry Points - Multi Page Application. All you need to do is create each page individually and import what you actually need for it, no fancy dynamic imports. So you need to configure webpack that each entry point is a standalone bundle/page and it will generate them with their associated name (see also output.filename):
entry: {
pageOne: './src/pageOne.jsx',
pageTwo: './src/pageTwo.jsx',
// ...
},
output: {
filename: '[name].bundle.js'
}
It's that simple, and it even makes the build process easier, as it automatically generates pageOne.bundle.js, pageTwo.bundle.js and so on.
As a final remark: Try not to be too smart with dynamic imports (pretty much avoid using expressions in imports completely), but if you decide to make a single page application and you only want to load what's necessary for the current page you should read Code Splitting - Using import() and Code Splitting - Using require.ensure, and use something like react-router.
I have been trying to figure out another way of handling i18n within FuelPHP (see here).
I decided to import the Symfony2 Translation component (using composer) to Fuel as a vendor and manage i18n with xliff files.
Here is my (simplified) code:
use \Symfony\Component\Translation\Translator;
use \Symfony\Component\Translation\MessageSelector;
use \Symfony\Component\Translation\Loader\XliffFileLoader;
...
class I18N
{
private static $translator = NULL;
....
public static function get($key)
{
# Load and configure the translator
self::$translator = new Translator('en_GB', new MessageSelector());
self::$translator->addLoader('xliff', new XliffFileLoader());
self::$translator->addResource('xliff', 'path/to/xliff/file', 'en');
# Get the translation
$translation = self::$translator->trans($key, $params);
# Return the translation
return $translation;
}
}
So at first I thought that was working great since I was testing it on a very small xliff file but now that I've generated the complete xliff catalogue (about 1400 entries) for my entire application, each request is really slow.
So the question is, is there a way to cache translations when using the Translation component the same way the whole Symfony2 Framework caches it natively?
The Translator Class from the FrameworkBundle has a constructor that accepts options in which you can define the cache_dir. Anyway I can achieve that using the Translation component?
Thanks for any help on that matter.
So what I did was to generate my own cache from xliff files, if it doesn't exist, which is nothing more than the translations as a php array and make the Translator Component load resources as ArrayLoader instead of XliffFileLoader. It's lightning fast now. Thanks to Touki in the comments for your interest.
I converted our Meteor site to support two languages, Dutch and English. To do this I made two folders for our templates (en and nl) and hooked everything up to our templating system so the router serves things correctly depending on which site you're on. The main body template is dynamic:
Template.body.content = function() {
var lang = Session.get("lang") == "en" ? "en_" : "";
var page = Session.get("page") || "home";
// if the template for the current language doesn't exist,
// fall back to Dutch version or show a 404
var template = Template[lang + page] || Template[page] || Template[lang + "error404"];
return template();
}
Everything works pretty well except that I have to write the following to expose a template value to both languages:
Template.en_foo.bar = Template.foo.bar = function() {}
For an example of this code as used in production, see our client-side blog code.
What's an elegant way to avoid this approach while still accomplishing the goal of a multilingual site?
What about this:
make a custom subscription and pass the language argument to a custom publish
the custom publish function returns only the selected language (optionally you can provide fallbacks if content is unavailable)
use just one template for all languages, filled with the right language from the subscription
use i18n package for the UI strings
Multi-languages applications is on the Meteor roadmap but it's planned in a long time...
Meanwhile you can use this atmosphere package.
I'd recommend heavily against keeping translated versions of your templates around. Unless your site is tiny. It might not seem so bad at first because you just copy them and translate the contents. But from then on you'll have to maintain both versions on any change, test both. And then somebody will suggest adding that third language and boom, triple damage to your brain.
We're using meteor-messageformat for translations. It comes with an interface that allows creating translations without having to look at template code. Anybody can translate.
Every time a tpl file is included the system first looks for a site-specific version of the file and falls back to a standard one if the site specific one does not exist. So perahps I put include "customer/main/test1.tpl". If our site is google, the system would first look for "customer/main/google_test1.tpl" and fall back to "customer/main/test1.tpl" if that file doesn't exist.
Note: Smarty 2.6.x
Did you know about the built-in template directory cascade? addTemplateDir and setTemplateDir allow you to specify multiple directories:
$smarty->setTemplateDir(array(
'google' => 'my-templates/google/',
'default' => 'my-templates/default/',
));
$smarty->display('foobar.tpl');
Smarty will first try to find my-templates/google/foobar.tpl, if not found try my-templates/default/foobar.tpl. Using this, you can build a complete templating cascade.
That won't be too helpful if you have lots of elements on the same cascade-level. Say you had specific templates for google, yahoo and bing besides your default.tpl. A solution could involve the default template handler function. Whenever Smarty comes across a template it can't find, this callback is executed as a measure of last resort. It allows you to specify a template file (or template resource) to use as a fallback.
So you could {include}, {extend}, ->fetch(), ->display() site_google.tpl. If the file exists, everything is fine. If it doesn't, your callback could replace _google with _default to fallback to the default template.
If neither template_dir cascade nor default template handler function seems applicable, you'll want to dig into custom template resources.