conedevelopment / i18n Goto Github PK

It would be better to trim whitespaces at the beginning and end of the string.
Related to the laravel documentation, my string looks like this:
'{1} 1 inaktives Meeting|[0,2,*] :cnt inaktive Meetings
There is always a whitespace between the number and the text like in the official laravel documentation. This whitespace is removed if laravel provides the translated string. With this library the whitespace remains.

Laravel results in: "1 inaktives Meeting"
This library results in: " 1 inaktives Meeting"

This could be a problem if I would add brackets or other content directly before or after the string.

Hello,
problem is that trans function in TranslationServiceProvider.php always has the same key
($translation = $file->getBasename('.php')) => trans($translation);

Because file name for all languages is the same, only directory names are unique for language. Like ../lang/en/auth.php ../lang/fr/auth.php

auth is always key for trans function and return value is always english(default).

------- EDIT
laravel setLocale is the problem. Sorry. Please delete this issue

I have run the vendor publish command again but my translation is not updating.

Is it possible to add an option to select which files we want to use for translations?
For the moment i think translations of all files are added. It could be huge in a big project, and Google doesn't like very much when a page take time to load.
Any solution?
Thanks for your help.

I'm putting translations directive in blade file and its working perfectly in local machine but when the project deployed on live server its not worked and doesn't render (still show @translations )
I was tried to clear (views ,cache ,config) and still not working.

See e.g. PrismJS/prism#1708

e.g. in Firefox 66

https://stackoverflow.com/a/50011952

i believe it would make more sense if importing the i18n already comes bundled with the translations.

as atm we need to do 3 steps

• add window.translations = @translations; to view
• import I18n
• init the lib let translator = new I18n(window.translations);

Hi,

I have this string:
{1} 1 Meeting|[0,2,*] :cnt Meetings
This doesn't work with this library for the option 0, 2, * (1 works) but perfect with laravel.

My workaround is to use this: {1} 1 Meeting|:cnt Meetings

But I think it would be great if the library does the same as laravel itself.

Otherwise big thanks for this great package. :)

Best regards,
Alexander

Since the translations are generated via blade directive, they are stored statically in the compiled templates. This is performance friendly, however, it does not track the current application locale.

It means, if the application local has been changed, the generated translations will have the previous locale.

1. Translation from JSON files are not exposed in window.translations.
   I was able to expose them using this following piece of code in I18nServiceProvider::translations().

        $translations = $translations->merge(
            collect(File::files(resource_path('lang')))->filter(function ($file) {
                return $file->getExtension() === 'json';
            })->mapWithKeys(function ($file) {
                return [
                    basename($file->getFilenameWithoutExtension()) => collect(json_decode($file->getContents(), true)),
                ];
            })
        );

2. When exposing translations, thoose having a key containing a . are not working.

Found out that (simplified) trans_choice(":count messages", 2) throws an error, while Laravel itself is fine with it. Did a bit of digging, and found that there's various cases where I18n.js behaves differently from the framework.

Testcases: https://jsbin.com/ruzaceyawo/edit?js,output
Laravel Framework testcase: https://github.com/laravel/framework/blob/9.x/tests/Translation/TranslationMessageSelectorTest.php

Another (seperate) issue is the "default pluralisation" rules are based on the en locale. Others can have more entries, and different rules.

E.g.

public function getPluralIndex($locale, $number)
    // ...
    case 'uk':   
        return (($number % 10 == 1) && ($number % 100 != 11)) ? 0 : ((($number % 10 >= 2) && ($number % 10 <= 4) && (($number % 100 < 10) || ($number % 100 >= 20))) ? 1 : 2);
    // ...
}

according to https://pineco.de/using-laravels-localization-js/ we get the default locale and cache it, but what happens when u change the locale ?

the lib can take care of this by switching the translation according to the current app locale which can be acquired by using props on the vue comp init and send it as an option to the class constructor.

then we check if the locale is found in the translations keys locales and either fallback to the default or display empty string, which could be another option sent to the class constructor

It would be great to bump the composer requirements to support Laravel 8.

Hello @iamgergo

Thanks for your work on issue #7, your solution efficiently makes the language switch.

However, I see that when updating a translation file, the change is not reflected in the @translations directive. To do it, I need to run again the view:cache command.

I found an issue where if there are multiple packages only the last one is added to the list of translations.

This is a cool library! It would be even cooler if instead of loading the translation json into the template, you wrote it out to a php file that sends an application/javascript content-type and injected an include for that file into the template instead. That would put all of the translation strings into an external include instead of embedding them in the page html, which would allow for caching in the browser.

Hello, its that time again..! Any chance of Laravel 10 support?

Hello, would you be able to update for Laravel 11? It looks like Shift already submitted a PR.

Hi,

Thanks for this. I have followed the instructions and installed / implemented this package successfully. Everything is working fine except when the translations are not available for any key in a particular locale, it is not fetching the translation from default one. Looks like fallback locale is not working for me.

Can you kindly suggest what could I be doing wrong?

Thanks,

By default, directives are cached so whenever their logic is changed, artisan view:clear must be called to ensure it is updated. Currently, the implementation of the @languages directive is that it returns an already computed language array.

While I understand that it has been done on purpose so that the translations don't have to be retrieved with every request or to be cached manually, it can become cumbersome if you're developing the app and constantly adding (or even changing) new language keys.

I propose, instead of changing the current implementation, which is optimal for production, to check if the app is not in production and, if so, simply delete the cache as suggested in Laravel's official documentation, with every request.

With that said, I have to thank you for this package. It has become a must in every project of mine where I'm using React components for some parts of the frontend. Very good job! 💙

It's a rare bug that I found today...

If you have any local package registered in your app, and you have i18n installed, laravel seems to be unable to register package commands with the typical code in the package Service Provider:

if($this->app->runningInConsole()){
$this->commands([
MyCommandClass:class,
]);
}

Hi there, it would be great for this package to support Laravel 9 :)

I think the only change beyond bumping the Composer requirements would be due to Laravel 9 moving the resources/lang folder to the top level of the project. I'm happy to submit a PR for this if that would help, just not 100% certain on how to best test the change.

By default, all translations are given to the frontend. This means that translations related to some feature that is not available to every user of the application (for example, an admin panel) could be discovered by just using the developer tools of the browser.

While the current behavior is enough for most cases, it is true that being able to see all translations can potentially become into a security problem, concerning the domain of the application.

To fix this I suggest implementing a filtering feature, which allows us to customize what translations are and are not available to the frontend. This is exactly the same the package https://github.com/tightenco/ziggy does with routes.

My proposal would be the following. The package would have available a configuration file that can set up whitelisting or blacklisting by providing an array of the translation files that should be filtered. According to the filtering configuration, the global languages JS variable would not contain translations for the files filtered out. Using filtered translations would have the same outcome as using a non existent key.