As long as you are consistent - you can use either one or combine them. php files is a bit more complicated as you will need to change all your keys to paths.īut it does not matter that much which one you will pick. The good thing is that they are pretty much interchangeable. This can be a problem if you have a lot of languages, and you need to translate the same string in all of them. If you have a lot of translation strings - you'll end up with a huge JSON file. If different languages require different translations for the same word in different contexts - you won't be able to do that. For example: _('Name') in auth/ and auth/ will result in the same translation. You will not be able to have context for the translation.This is not ideal, and you should only use it to translate the default Laravel translations as seen here But you can have "auth.Name": "Name" in the same file which will load. It's not possible to write _('auth.Name') and have a JSON file with the auth key and Name key inside of it. This means that all your text will be in a single file and a single layer. Using the same key in multiple views will result in the same translation. Passing these files to a non-dev translator is much easier: they don't need to worry about technical details.You can write full sentences as a key and later have them translated.This allows us to write complete text in the _() function key and not worry about a path or missing translations. In our blade, the translation will look like this: They contain a single list with all the translation strings. Potentially bigger mess: things can quickly get out of hand, and you might end up with a lot of files and folders.Inconvenient for non-dev translator people: they will have to work with multiple files/paths and understand what they can and can't change in the code.Otherwise, you risk displaying an ugly key to the end user. You need to type all strings in the files immediately.This is useful if you have a lot of translation strings, and want to add some context to them. You can have identical keys in different files: _('') and _('validation.name') will both return the same translation but can be managed separately.This will make it easier to find the translation you are looking for. For example: auth.php, validation.php, pagination.php, etc. You will most likely separate your translations by the feature or sub-system. If there is no translation with that key, or if that file doesn't exist - you won't get an error, you'll just get the same key back: All the other dot-separated parts are the keys of the array inside that specific file. See that parameter? The first part of it is the filename: /lang//.php. So, the code _('') will load the translation string from the auth.php file and return the Name string. That will also work in the latest Laravel version but is considered an old/obsolete approach. In earlier Laravel versions, you may find that translations are stored in the /resources/lang folder. This will create a lang folder in your root directory and add the en folder inside with default translation strings from Laravel core.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |