Localisation

Localisation support was added to accommodate users that require their their tables to have multi-lingual support.

This is completely optional of course, if you don't need it you can forget about this page entirely.

There are 3 parts that are localised:

• DataTables
• Column titles
• Actions

📘

If no translation is found, the string used for translating is returned.

Let's go over each one together.

DataTables

This jQuery plugin comes with its own way of handling localisation.

DragonFly\Lists tries not to come in the way of that, however you will have to register each language individually.

First you start of by download the translations that you need.
After you have finished downloading them you should copy them to your public path, assets/locales to be exact.

For example, if I downloaded french, I'll put the French.json file into public/assets/locales.

Next we'll have to register it, your config folder should have a lists.php file with a locales key that takes an array.

Any language that's not english should be added here.

• The key should be the same as laravel's locale identifier
• The value should be the name of your language .json file

In our example case I would add the following for the french localisation:

PHP

    'locales' => [
        'fr' => 'French.json',
    ]

Now, when you're Laravel app's locale is changed to 'fr', the dataTable's locale will also change.

📘

If there's no locale defined, or it's been defined incorrectly, dataTables will use the default, english, locale.

Column titles

Column titles can be defined in 3 ways:

• Common titles could be defined globally
• Under a specific table namespace
• Custom

Global definition

When you have a column title that you use on multiple tables (like 'actions' in my case) it's easier to have them in 1 place.

These global column title are defined in tables.php under the key titles in your locale directory (this would be resources/lang/en/tables.php when you use english as your locale).

In my case it would look for the actions key in that file's titles key and use its translation when rendering the table.

Table specific

If you'd rather make a translation file for every table, you can, the translation file's name will be the following format: 'table_' . snake_case($this->kernel_identifier).

For example, if you're table's $kernel_identifier is 'user', the translation file would be named 'table_user.php'.

There it will look for a key that's the same as the value of the title you have defined for your fields (located under the titles key).

Custom

Of course it might be easier to have your translations in 1 place for specific pages that also implement a Lists Table.

if that's the case you could just define your translation identifier as the field's title.

e.g. if you defined your field's title as admin.users.table.email it will look for the admin translation file and dig into the returned array.

Actions

Messages

These get translated just the same as column titles, the only difference would be the key they should be stored under. They are also able to use the ':slug' tag as a variable.

Instead of titles, they should be stored under messages (unless they're custom or shouldn't be translated of course).

UI & defaults

If you ran vendor:publish after installing this package the english translation file should have been copied into your resources/lang/packages/en/lists/actions.php.

It will contain english translations for the default messages and the UI controls.

🚧

Please follow the same folder structure when adding new languages.