Installation 4.2

1. Require this package in your composer.json and run composer update (or run composer require vsch/laravel-translation-manager:* directly):

   "require": {
        "vsch/laravel-translation-manager": "~1.0"
    }

   if you are not going to be customizing the web interface it is highly recommended that you add automatic asset publishing for this package after upgrade in your project's composer.json:

   "scripts": {
        "post-update-cmd": [
            ... other suff ...
            "php artisan asset:publish vsch/laravel-translation-manager",
            ... other suff ...
        ]
    },

   Otherwise a future update, that needs new assets, will not work properly. composer does not run post-update scripts of packages.

   Here is a full scripts section of a standard Laravel 4.2 project composer.json should look like after the change.

    "scripts": {
        "post-install-cmd": [
            "php artisan clear-compiled",
            "php artisan optimize"
        ],
        "post-update-cmd": [
            "php artisan clear-compiled",
            "php artisan asset:publish vsch/laravel-translation-manager",
            "php artisan optimize"
        ],
        "post-create-project-cmd": [
            "php artisan key:generate"
        ]
    },
   

2. After updating composer, add the ServiceProviders to the providers array in app/config/app.php and comment out the original TranslationServiceProvider:

   //'Illuminate\Translation\TranslationServiceProvider',
    'Vsch\TranslationManager\TranslationServiceProvider',
    'Vsch\TranslationManager\ManagerServiceProvider',
    'Vsch\UserPrivilegeMapper\UserPrivilegeMapperServiceProvider',
   

   The TranslationServiceProvider is an extension to the standard functionality and is required in order for the web interface to work properly. It is backward compatible with the existing Translator since it is a subclass of it and only overrides implementation for new features.

3. add the Facade to the aliases array in app/config/app.php:

   'UserCan' => 'Vsch\UserPrivilegeMapper\Facade\Privilege',

4. Publishing and running migrations

   You need to publish then run the migrations for this package:

   $ php artisan migrate --package="vsch/laravel-translation-manager"

5. Publishing the configuration

   You need to publish the config file for this package. This will add the files app/config/packages/vsch/laravel-translation-manager/config.php and app/config/packages/vsch/laravel-translation-manager/local/config.php, where you can configure this package.

   $ php artisan config:publish vsch/laravel-translation-manager

6. You need to publish the web assets used by the translation manager web interface. This will add the assets to public/packages/vsch/laravel-translation-manager

   $ php artisan asset:publish vsch/laravel-translation-manager

7. Configuring WebUI Route

   You no longer need to add the Controller to your routes.php, this is done by the TranslationManagerServiceProvider in boot(). However if you want to change the before filter or the prefix then you should edit the config values 'web_root' and 'web_root_before' entries. The default root is 'translations'. This will make the translation manager available at http://yourdomain.com/translations just as before.

8. Setting up user authorization

   TranslationManager uses the vsch/user-privilege-mapper package that creates a mapping layer between your User model implementation and the need to test user privileges without knowing the implementation. You need to name privileges for the UserPrivilegeMapper via the Laravel macro mechanism. This should be done in the initialization files. A good place is the filters.php file, add the following if your User model has is_admin and is_editor attributes to identify users that have Admin and Editor privileges:

   \UserCan::macro("admin_translations", function ()
    {
        return ($user = Auth::user()) && $user->is_admin;
    });
   
    // return false to use the translator missing key lottery, true to always check missing keys for the user
    \UserCan::macro("bypass_translations_lottery", function ()
    {
        return ($user = Auth::user()) && ($user->is_admin || $user->is_editor);
    });

   In this example the User model implements two attributes: is_admin and is_editor. The admin user is allowed to manage translations: import, delete, export, etc., the editor user can only edit existing translations. However, both of these users will always log missing translation keys so that any missing translations will be visible to them instead of relying on the missing key lottery settings.

9. Yandex assisted translations

   Assisted translations requires setting the yandex_translator_key to your Yandex API key in the config/laravel-translation-manager.php file, it is free to get and use. See: https://tech.yandex.com/translate/

10. Overriding the Web Interface Translations

    If you want to override the Translation Manager web interface translations or add another locale you will need to copy the language files to your project and create the Laravel 4 package override directory structure app/lang/packages/{locale}/laravel-translation-manager/message.php from the vendor/vsch/laravel-translation-manager/src/lang/{locale}/message.php

11. Customizing Views

    If you want to customize views for the Translation Manager web interface you will need to copy the views to your from vendor/vsch/laravel-translation-manager/src/views to app/views/packages/vsch/laravel-translation-manager. See: Modifying the default Views