Download the PHP package winter/wn-translate-plugin without Composer

On this page you can find all versions of the php package winter/wn-translate-plugin. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Example code of winter/wn-translate-plugin

Informations about the package wn-translate-plugin

Translate Plugin

Adds multi-lingual / localization capabilities to the frontends of Winter CMS websites.

Supports:

Installation

This plugin is available for installation via Composer.

After installing the plugin you will need to run the migrations and (if you are using a public folder) republish your public directory.

Selecting a language

Different languages can be set up in the back-end area, with a single default language selected. This activates the use of the language on the front-end and in the back-end UI.

A visitor can select a language by prefixing the language code to the URL, this is then stored in the user's session as their chosen language. For example:

Language Picker Component

A visitor can select their chosen language using the LocalePicker component. This component will display a simple dropdown that changes the page language depending on the selection.

If translated, the text above will appear as whatever language is selected by the user. The dropdown is very basic and is intended to be restyled. A simpler example might be:

Message translation

Message or string translation is the conversion of adhoc strings used throughout the site. A message can be translated with parameters.

A message can also be translated for a choice usage.

Or you set a locale manually by passing a second argument.

Themes can provide default values for these messages by defining a translate key in the theme.yaml file, located in the theme directory.

You may also define the translations in a separate file, where the path is relative to the theme. The following definition will source the default messages from the file config/lang.yaml inside the theme.

This is an example of config/lang.yaml file with two languages:

You may also define the translations in a separate file per locale, where the path is relative to the theme. The following definition will source the default messages from the file config/lang-en.yaml inside the theme for the english locale and from the file config/lang-fr.yaml for the french locale.

This is an example for the config/lang-en.yaml file:

In order to make these default values reflected to your frontend site, go to Settings -> Translate messages in the backend and hit Scan for messages. They will also be loaded automatically when the theme is activated.

The same operation can be performed with the translate:scan artisan command. It may be worth including it in a deployment script to automatically fetch updated messages:

Add the --purge option to clear old messages first:

Content translation

This plugin activates a feature in the CMS that allows content files to use language suffixes, for example:

Machine translation on copy

Every multilingual backend field has a "copy from another locale" action. When a machine-translation provider is configured, that action can also translate the copied content into the target locale. Supported providers: Google Cloud Translation and DeepL.

This is opt-in and invisible by default: with no provider configured, the copy action stays a plain one-click copy — no provider popup, no extra UI. As soon as a provider key is set, a small "translation method" picker appears so the user can choose None, Google or DeepL when copying.

Configuring a provider

The easiest way is the backend settings screen: Settings → Translation Providers. It has a guided tab for each provider with step-by-step instructions (and direct links to each provider's console) beside a masked field for the API key:

Keys entered here are stored in the settings table and used ahead of any environment/config value. The screen is gated by the winter.translate.manage_settings permission.

Prefer to configure via environment instead (e.g. for deployment)? The same providers read from config/config.php (or an app override in config/winter/translate/config.php), keyed via environment variables:

An env/config key keeps working even with the settings screen left blank — the settings page shows it as configured via environment and only overrides it when you enter a key. A provider only appears in the picker once its key is set (via either method). When exactly one provider is configured it is pre-selected automatically; with several configured the picker defaults to None so translation stays a deliberate choice.

Getting a Google key: in the Google Cloud Console create/select a project, enable billing, enable the Cloud Translation API, then create an API key (restrict it to the Cloud Translation API).

Getting a DeepL key: sign up for the DeepL API, then copy your Authentication Key for DeepL API from Account → API keys.

Translating nested fields (repeater / nested form / blocks)

For composite widgets, only the sub-fields that opt in are machine-translated — every other value (images, switches, numbers, …) is copied verbatim. A sub-field opts in with translatable: true in its field definition:

If no sub-field is marked translatable, the widget is still copied between locales — the nested values simply aren't translated. This is declared per field, so different widgets and models can each translate exactly the sub-fields that make sense for them.

Adding a provider

Implement Winter\Translate\Providers\TranslationProvider (or extend AbstractTranslationProvider for batching + timeouts) and reference the class from config:

Mail template translation

This plugin activates a feature in the CMS that allows Mail template files to use language suffixes, for example:

Model translation

Models can have their attributes translated by using the Winter.Translate.Behaviors.TranslatableModel behavior and specifying which attributes to translate in the class.

If you store structured data in a JSON column (e.g., additional_data), and you want to make nested fields translatable, use square bracket notation to define the path to the nested attribute.

The attribute will then contain the default language value and other language code values can be created by using the translateContext() method.

You may use the same process for setting values.

The lang() method is a shorthand version of translateContext() and is also chainable.

This can be useful inside a Twig template.

There are ways to get and set attributes without changing the context.

Extending a plugin with translatable fields

If you are extending a plugin and want the added fields in the backend to be translatable, you have to use the 'backend.form.extendFieldsBefore' and tell which fields you want to be translatable by pushing them to the array.

Theme data translation

It is also possible to translate theme customisation options. Just mark your form fields with translatable property and the plugin will take care about everything else:

Fallback attribute values

By default, untranslated attributes will fall back to the default locale. This behavior can be disabled by calling the setTranslatableUseFallback() method.

Indexed attributes

Translatable model attributes can also be declared as an index by passing the $translatable attribute value as an array. The first value is the attribute name, the other values represent options, in this case setting the option index to true.

Once an attribute is indexed, you may use the transWhere method to apply a basic query to the model.

The transWhere method accepts a third argument to explicitly pass a locale value, otherwise it will be detected from the environment.

URL translation

Pages in the CMS support translating the URL property. Assuming you have 3 languages set up:

There is a page with the following content:

The word "Contact" in French is the same so a translated URL is not given, or needed. If the page has no URL override specified, then the default URL will be used. Pages will not be duplicated for a given language.

URL parameter translation

It's possible to translate URL parameters by listening to the translate.localePicker.translateParams event, which is fired when switching languages.

In YourModel, one possible implementation might look like this:

Query string translation

It's possible to translate query string parameters by listening to the translate.localePicker.translateQuery event, which is fired when switching languages.

For a possible implementation of the YourModel::translateParams method look at the example under URL parameter translation from above.

Extend theme scan

Settings model translation

It's possible to translate your settings model like any other model. To retrieve translated values use:

Conditionally extending plugins

Models

It is possible to conditionally extend a plugin's models to support translation by placing an @ symbol before the behavior definition. This is a soft implement will only use TranslatableModel if the Translate plugin is installed, otherwise it will not cause any errors.

The back-end forms will automatically detect the presence of translatable fields and replace their controls for multilingual equivalents.

Messages

Since the Twig filter will not be available all the time, we can pipe them to the native Laravel translation methods instead. This ensures translated messages will always work on the front end.

User Interface

Switching locales

Users can switch between locales by clicking on the locale indicator on the right hand side of the Multi-language input. By holding the CMD / CTRL key all Multi-language Input fields will switch to the selected locale.

Integration without jQuery and Winter CMS Framework files

It is possible to use the front-end language switcher without using jQuery or the Winter CMS AJAX Framework by making the AJAX API request yourself manually. The following is an example of how to do that.

The HTML:

All versions of wn-translate-plugin with dependencies

PHP Build Version
Package Version
Requires php Version >=8.1
winter/wn-backend-module Version >=1.2.8 || dev-develop
composer/installers Version ~1.0
guzzlehttp/guzzle Version ^7.15.2 || ^8.0.1
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package winter/wn-translate-plugin contains the following files

Loading the files please wait ...