The future of Laravel-lang
caouecs opened this issue · 48 comments
I started this repository the 30 May 2013, with the help of Evgeny Kovalev, because Taylor Otwell didn't want to manage translations directly in Laravel Framework. We started with French, Russian, Dutch, Polish, Turk and Chinese versions, and now, we have 75 languages in the package.
I admit that sometimes, I merged pull requests without review ; most of the time, because I didn't understand the language ( I'm French you know ). But I try to check some translations, the homogeneity and coherence of words, but it's not easy. Because some prefer to use this or that word for an expression, or because such a word is better for his project... Sometimes, I ask the review of another person, sometimes, with some authors, I know I can merge immediately. But, it's not optimal for the quality of translations.
I don't say I want to stop, just take it easy, and I think it's time to detach this project from my Github account, create a new organization to manage it, include persons which will review pull requests and will choice the future of this project.
So I'm open for proposition about the name of organization ( Laravel-Lang ? ) and who want to join it.
Ideas :
- list of referents by language : they are sollicited for a merge
I like the idea of a gh organisation, and I can help for the french translation.
I think laravel-lang is a good idea!
Yes, a list of referents by language is a good idea
Laravel-Lang is a great idea and the namespace is free.
I can be responsible for the Russian-language translation of files.
I see several options:
For all options, you definitely need to separate the namespaces:
https://github.com/Laravel-Lang
/en
/fr
/ru
/...
Option 1:
Only translation files are stored in the repositories, and they will be installed by a common package.
Option 2:
Make each localization self-contained.
composer require laravel-lang/en
composer require laravel-lang/fr
composer require laravel-lang/ru
composer require laravel-lang/...
At the same time, create a common package for installing all locales:
composer require laravel-lang/main
Or leave this choice for package managers.
Personally, I prefer the second option without the parent package.
BUT I see a flaw in this scheme - you need to think over how to release languages. You should probably follow the Illuminate method, where all modules have a version of the parent package installed. Or go the larapack/hooks way.
I want to say that you need to think over the actions in such a way that the user does not install all localizations at all as dependencies. So I'm thinking about how best to do the process of installing and updating packages.
@overtrue, @arcanedev-maroc, what do you think?
75 + 1 ( for the main ) repositories ?
I don't mind taking over pt_PT.
@caouecs, maybe create a table with the names of those who are ready to be responsible for localizations?
In my opinion, this will make it easier for us and for those who want to take an active part in the life of the package.
I copied the table in the subject
I don't mind taking over pt_PT.
Other question : we work with pt or pt_PT ? fr or fr_FR ? etc...
I copied the table in the subject
Ok. I removed the table from my post :)
I don't mind taking over pt_PT.
Other question : we work with pt or pt_PT ? fr or fr_FR ? etc...
i think we should go with language tags
https://www.w3.org/International/questions/qa-choosing-language-tags
@caouecs I can manage nl and de translations too btw!
I think it would be great to have scripted installation for the package, by using publishing, making it easier to use for a wide range of users. I copy-paste the files, but I think it's not the most efficient way to do it.
Another way could be a package "main" which contains just a download script, downloading the required files directly from the corresponding repo and installing them where needed.
- laravel-lang/main
- laravel-lang/langs
Usage could be like :
php artisan laravel-lang:install fr
What do you think of this architecture?
I can be responsible for the danish translation.
Projects based on this package
- LaravelLang by ARCANEDEV - Translations manager and checker for Laravel.
- Laravel-lang by overtrue - Command to add languages in your project.
- laravel-lang-publisher by Andrey Helldar - Easy installation and update of translation files for your project.
@WhereIsLucas, https://github.com/andrey-helldar/laravel-lang-publisher
Didn't see the projects, this could be great to combine the projects into the organization?
@WhereIsLucas, https://github.com/andrey-helldar/laravel-lang-publisher
Didn't see the projects, this could be great to combine the projects into the organization?
What I mean is that the Laravel Lang package provides translation source files. Translation managers are responsible for publishing translations within the framework.
Now Fred is changing his style of work. As soon as he provides new data, translation managers will be added to his support.
hello, I can take over the Ukrainian(uk) localization
hello, I can take over the Ukrainian(uk) localization
Hello,
it's your first time on this project, no ?
You can help on json and validation-inline 👼
https://github.com/caouecs/Laravel-lang/blob/master/todo.md#uk
Thanks
@MrAlKuz, ping
I want to contribute to Nepali language.
I can be responsible for the Nepali or Nepalese (नेपाली) translation.
I want to contribute to Nepali language.
I can be responsible for the Nepali or Nepalese (नेपाली) translation.
https://github.com/caouecs/Laravel-lang/blob/master/todo.md#ne thank you ;)
We follow ISO-639-1 and Ukrainian is UK https://en.wikipedia.org/wiki/Ukrainian_language
You confuse country and language. The Ukrainian language is not just spoken in Ukraine, it's the same thing with French, Spanish, English...
Greetings, thanks for the invitation to the project, I will be happy to help in the development and prosperity of this business, I also want to immediately notice that the "UK" code (United Kingdom) is not correct for Ukraine, but "UA" is correct
Country abbreviation - UA
Language abbreviation - UK
Hello, i can manage and be responsible for Serbian language (sr_Cyrillic & sr_Latin)
I'll add missing lines for those two.
Thank you @LukaLatkovic
no need to be responsible to propose pull request for translations ;)
@caouecs I meant to manage Serbian translations :) and help with organisation :)
Hello, I can help you to manage the Indonesian language (ID)
Hello, I can help you to manage the Indonesian language (ID)
Can you translate validation-inline.php and id.json ?
Hello, I can help you to manage the Indonesian language (ID)
Can you translate validation-inline.php and id.json ?
Sure
Thank you, @caouecs. This is a great project. As a native speaker and college-level professor of Arabic (and linguistics), I will be glad to take care of (or/and help with) Arabic.
Good idea @caouecs. that's will keep all translations updated and been more trusted. So, I'll take care of Arabic as always
two managers for Arabic ? No problem, if it's ok for you ;)
two managers for Arabic ? No problem, if it's ok for you ;)
I'll just leave it here 😀
two managers for Arabic ? No problem, if it's ok for you ;)
I think two heads are better than one. If there are any nuances in translation and perception, @Khuthaily and @mohamedsabil83 will be able to discuss this and choose the best option. Do you agree?
two managers for Arabic ? No problem, if it's ok for you ;)
I think two heads are better than one. If there are any nuances in translation and perception, @Khuthaily and @mohamedsabil83 will be able to discuss this and choose the best option. Do you agree?
Totally agree with you
done ;)
@caouecs, can you invite @Khuthaily to our team?
I did it this morning ( French hour of course )
@caouecs I noticed that some translations are missing in Jetstream. I would like to know if there are plans for supporting Jetstream and I could help with the dutch translations for it.
@hugomeruma,
Laravel Jetstream is a preset package. It does not use the trans() (__(), so to say) method calls in the code or the @lang methods in the Blade templates.
This package connects to your application, where translation files should already be or one of the translation managers installed.
When you install Jetstream, the package publishes the template files in which you need to make a localization call.
+1 for @andrey-helldar comment and I think the project needs a work about localization.
So, for the moment, the best is to do pull requests to laravel-jetstream for localization, and after, I think it will be possible to create a new package for translation of laravel-jetstream
two managers for Arabic ? No problem, if it's ok for you ;)
I think two heads are better than one. If there are any nuances in translation and perception, @Khuthaily and @mohamedsabil83 will be able to discuss this and choose the best option. Do you agree?
Totally agree with you
Perfect; thank you, @caouecs, @mohamedsabil83, and @andrey-helldar.
@caouecs, I began to notice the emergence of questions indirectly related to this topic.
I think it can be closed, and new questions can be posted in new issues.
ok