Localization of Horizon and Telescope projects #43699
Replies: 1 comment 3 replies
-
|
Personally I would agree with you that language translations should be provided on all core Laravel repos, but in the end there has to be someone who makes decisions and they have to have some policies to ensure that their decisions are reasonably consistent, and for Laravel that is Taylor and this is his policy. I also have had similar close messages to PRs I have submitted, but in my case they could be provided in an alternative way - or indeed there were package(s) that did what I wanted. The question about whether it is the best policy is not clear-cut. There is a definite up-side to pushing minor functionality into packages as Taylor's close message indicates, but that is fine when the functionality you want to add can indeed be added with a package, but obviously there are some functions that cannot be simply added with a package. The other downside is that this policy creating a package "marketplace" that becomes VERY fragmented, and developers have to search for packages and when they find them they can never be certain about their longevity, support etc. I would personally respond by posting a comment in each of the two PRs saying that: a. This functionality is not really suitable for delivery using a package because it is integral to the existing code and cannot be bolted on; And on this basis, can he reconsider. You can also solicit votes for / against such inclusion here in this discussion to see what the level of community support is, and see whether others believe differently to me i.e. that this functionality can be delivered as a package. Finally, there may be some mileage in reaching out to the members of the Laravel Lang team. They would be the people who have to support the translations of Horizon and Telescope, so having their support (i.e. that they have the capacity to undertake the translations) will IMO also be essential to getting such PRs accepted. (I would also caution you to treat the Lang Team as a team and not try to lobby individuals as this will create dissent and will likely be viewed poorly.) |
Beta Was this translation helpful? Give feedback.
-
|
There is a nuance: the message that Taylor leaves when the PR is closed is his standard "stub". He always writes it when rejecting any PR. And the external package would really work, if not for one BUT: in this case, you would have to fork the repositories and release projects under different names, which is wrong. Because the Horizon and Telescope packages initially do not allow the use of multilingualism, and the front-end part gets into the application in an already compiled version. About my PRs: in some places I made line breaks only because such a construction, in my opinion, looks and reads much better than in one line. Regarding the Laravel Lang team. We currently have 23 people in the team and not everyone can immediately respond to some messages. For example, 4 people responded to my question "is it necessary?": https://github.com/Laravel-Lang/lang/discussions/2321 At the same time, in one of the Telegram chats, people voted like this:
The nuance of this statistic is that the survey was conducted in a chat for beginners, in which not everyone knows what Telescope is, and even some experienced administrators have never heard of Horizon. BUT there is one comment that says this: since Laravel provides translation for its other projects, then it is worth doing it for Telescope with Horizon. As for the Laravel Lang team, we are happy to add something new. For example, new translation keys for Laravel Nova 4.12.13 at
In addition, the Laravel Lang team was created to translate Laravel projects into other languages. We also have our own Now, if someone with a wider cross-national audience launched such a survey, then the result would be more accurate. But in the case of multilingual applications, there are two such options: either the Laravel Lang team, which does not have many public faces with a large number of subscribers, or the Laravel team as the main developers of the multilingual product. And whether Taylor needs it is a question. But, judging by the closed PR, it is not necessary. |
Beta Was this translation helpful? Give feedback.
-
|
I fear that there are all sorts of assumptions in the above, esp. in the survey results. You really needed to ask: a. Separately for Telescope and Horizon; It is easy to find examples that support your case - but that is cherry picking because there may be many reasons that do not support your case that you may not even know about. In the end, I support Taylor's decision because there has to be a decision maker and they have to have a consistent approach even if I / you don't agree with it. My advice is for you to accept the decision as valid, and not gripe about it being "wrong" but instead to show why it should be done by PR and not a package, and why there is support for it from the community and / or the Lang team. But in the end, you may need to give it up as something that you cannot persuade people about. (See faster-cpython/ideas#328 for an example of my failure to persuade.) P.S.
Agreed - there are some changes which don't make sense to create as a package, but for which there is a need and which only make sense to do as a PR - and IMO this is one (or two) of them. |
Beta Was this translation helpful? Give feedback.
-
I agree. And so I created a discussion here in the hope that someone might also be interested in translating these packages. I'm not a public figure, so I can't conduct a survey and all I can do is wait for a possible answer. Also, I do not dispute Taylor's decision in any way, but I would be interested to know the reason for closing the PR. He does not always close PR due to global reasons. In practice, I have come across the fact that PRs were closed simply because they were sent to the wrong branch. For example, in one of my old PRs, I considered that the added functionality, according to the "Contribution Guide", was a minor change compatible with older versions of Laravel, and submitted it to the main working branch. Taylor came and also closed my PR leaving a default message. After a while, the guys from the Laravel team suggested what should be pushed to the I perfectly understand that he has a lot of work, but such closures are confusing. It is one thing if the PR is closed because Taylor does not want the proposed functionality, and quite another if he simply did not like, for example, a line break. I think many will agree that such "one-way" code reviews make developers think about whether something needs to be improved in Laravel at all and offer it. That is why we have, as you put it, a marketplace for various packages. And they also have their own problems, but they do not relate to this topic, so we will not talk about them. Returning to the topic of discussion, my personal opinion is that if the majority of projects support multilingualism, then it should be added to other projects.
Thus, we see that out of 15 active projects, two do not have multilingual support, and four do not need it. At the same time, I also understand that I can never wait for a response from the Laravel team, since I asked Taylor, but no one answered. It is likely that we will just have to abandon this idea. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I recently created a PR with a proposal to localize the interfaces of the
laravel/horizon#1175andlaravel/telescope#1244projects, but the next day @taylorotwell closed them.In my opinion, it would be cool to have a fully multilingual application including such nodes as Horizon and Telescope.
Our Laravel Lang team supports translations of all Laravel projects from native speakers, but this list does not include Horizon and Telescope.
I would like to know what is wrong with my PRs, that they were just silently closed without paying attention to such useful functionality.
Beta Was this translation helpful? Give feedback.
All reactions