-
Notifications
You must be signed in to change notification settings - Fork 84
Configuration
The config file config/laravel-translation-manager.php
has comments that provide a description
for each option. Note that when admin_enabled
is set to false
then translation management is
limited to editing existing translations all other operations have to be done through the
command line. Ideally, this option needs to be dynamic based on user privileges so that
translators cannot delete translations or administer translations but admins can. See
Installation: step 8.
By default the primary locale is en
. The primary locale determines what language is used for
the source text for the translate button in the edit pop-up and can be changed in the web
interface for the current session. When editing the text for the primary locale a button in the
edit pop-up allows you to convert the text of the key to a default value (change . - _ to
spaces, capitalize first letter of each word) that way you can generate descent placeholder text
to continue development and replace it with more meaningful value later.
By default the configuration will load all translations found in the standard Laravel locations.
Below {vendor}
, {package}
, {locale}
, {group}
are placeholders for their corresponding
values referring to vendor name, package name, locale string and translation group. The
translation group will consist of optional sub-directory tree and the file name, allowing you to
organize your translation files.
/resources/lang/{locale}/{group}.php
: Standard project translation files
/resources/lang/vendor/{package}/{locale}/{group}
: Package translation override files.
/workbench/{vendor}/{package}/resources/lang/{locale}/{group}
: Translation files for packages that you are developing in the current project. Laravel 4.2
style but the directory layout updated to version 5 standard. These will have a group prefix
of wbn:
in the database and web interface to distinguish them from the standard Laravel
package namespaces.
/vendor/{vendor}/{package}/resources/lang/{locale}/{group}
: Translation files for packages that are dependents of your project. By default no
translation files are loaded from this section. You will need to edit the configuration file
for the 'vendor' section and list the packages you want to include in the 'include' array in
the form 'vendor/package'. These will have a group prefix of vnd:
in the database and web
interface to distinguish them from the standard Laravel package namespaces
The default configuration file also has entries for two packages whose translation files'
location and naming convention does not follow Laravel conventions and require more tweaking to
allow import/export of their language files. These non-standard layouts can only be included in
the wbn:
or vnd:
prefixed namespaces.
If you published the views to your project in Installation: step 11 then
you can customize them to your liking. The package view directory also contains a
layouts/master.blade.php
file for a default layout. The intent is for you to provide your own
master layout that the index.blade.php will extend so it can match your site's style.
By default users that have translation access who are not administrators, ie.
UserCan::admin_translations
returns true
, can modify all locales.
To enable per locale access control for these users you need to set user_locales_enabled
in
the configuration file to true
and configure per user locales in the ltm_user_locales
table.
The user locales are indexed by currently logged in user's email.
NOTE If the user email is not found in the table or if the locale
list is null or empty
then the user will have access to all locales.
Column | Type | Description |
---|---|---|
user_email |
String(255) |
value returned by Auth::getUser()->email
|
locales |
Text |
comma separated list of locales the user is allowed to modify |
Users who do not have access to a locale will not be allowed to modify its translations. They will see these translations as text instead of a link that opens the edit pop-up.
If you have your translation table(s) in a database other than the default used by the default connection you will need to add the name to the configuration file:
/**
* used to provide an alternate database for the translation related tables
*
* @type string Database name alternate to the default
*
* if blank or not defined then default connection's database name will be used.
*
*/
'database_name' => '',
If you want to be able to access multiple databases for the translation manager from one set of
language files you can configure the db_connections
option in the config file. Here is what I
use to access the production server's translations from my local development environment:
/**
* @type array list of alternate database connections and their properties indexed by app()->environment() value,
* default connection settings are taken from config, so only add alternate connections
*
* NOTE: If database_name is missing then the globally defined database_name will be used for that connection.
* If database_name is blank then connection's database name will be used. Otherwise the given
* database name will be used for all translation tables
*
* description is used to display the connection name, default connection is displayed as 'default' in
* the web interface.
*
* indatabase_publish of:
* 0 - means use files only and publish to files.
* 1 - means use cache for publishing modifications. No files are written out
* 2 - means use cache for publishing modifications but also write out the files.
* useful for publishing to files while leaving all flags in the database as
* they would be after publishing only to cache.
*/
'db_connections' => array(
'local' => array(
'mysql_prd' => array(
'description' => 'production',
'indatabase_publish' => 2,
'database_name' => '',
),
),
),
The option is an array of environment names which in turn contain database connection names which list the options to use for that connection.
description
: the string to use in the web interface combo box to represent this connection. If the
description is empty or missing then the connection name will be used.
indatabase_publish
: the setting for indatabase_publish
to use for this connection. If this option is missing
then the global configuration indatabase_publish
will be used. Setting this value to 2,
will write to the local translation files but leave the database in a state to serve changed
translations from the cache. Note that with indatabase_publish
set to 1 or 2 publishing
will not reset the changed flag for translations and these will continue to show up in the
dashboard as changed
.
- 0: use files only and publish to files.
- 1: use cache for publishing modifications. No files are written out
- 2: use cache for publishing modifications but also write out the files. Useful for
publishing to files while leaving all flags in the database as they would be after
publishing only to cache.
database_name
: the setting for database_name
to use for this connection. If this option is missing then
the global configuration database_name
will be used. An empty string will cause this
connection's default database to be used. Otherwise, it is the name of the database where
the translation tables are to be found.
-
After updating the remote translations you need to go into translations page on the remote server and do a
publish all
so that either the files or the cache is updated with new translations. -
After deploying a new version of the application, with updated translation files on the servers, you should do an
Import
withOnly add new translations
. This will import any new translations and reset the cache.