You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are now two pull requests. 🤦♂️ #14 and #15.
They differ in the handling of the auth file. #15 is more structured while #14 has a different approach. @danharrin please take the approach you consider more 'laravel-like'.
Hey, we've just been discussing internally the best way to approach this.
I prefer translation keys like you used in #15, but Liam makes a good point that it's not very beginner friendly for a boilerplate, and he would prefer a fix like #14.
Let's see what the community thinks is the best option.
I absolutely prefer using keys in a real application that needs full translations, especially combined with a tool like i18n-ally to see the real values inline with code lens, which mitigates the issue of not seeing the real string somewhat.
However, I don't think that it's a very friendly way for most people, especially as we can't force tooling like that, as the majority of apps don't even need internationalisation support. The simpler approach of using the fill string is indeed less flexible, but in my opinion it's so much easier for people to understand exactly what it is, which I think is important in a preset.
@imliam In my opinion it should become clear when you read the english strings.
However is it a possibility to add both as a option? As far as I know the php artisan ui does support options.
@Wulfheart, I'm really sorry I didn't notice this issue sooner. 😬🙏
I too prefer using translation keys for apps that need full translations, but IMO most of the apps won't need it. Adding translation keys like this adds an overhead of a translation file and makes it a bit harder to understand for beginners. But I guess ultimately it is up to the authors and community to decide.
I'd prefer it the other way around myself (the full strings by default because it's easier for people to understand, swapping out to the keys for people that actually want to translate stuff.
We can do whatever custom logic is needed - see the src directory. The service provider can register whatever extra flags it needs to call any custom logic. Right now the most we're doing is using str_replace() on a couple of files, but should be possible to replace all these strings in a loop I guess
Activity
Wulfheart commentedon May 8, 2020
There are now two pull requests. 🤦♂️

#14 and #15.
They differ in the handling of the auth file. #15 is more structured while #14 has a different approach. @danharrin please take the approach you consider more 'laravel-like'.
danharrin commentedon May 8, 2020
Hey, we've just been discussing internally the best way to approach this.
I prefer translation keys like you used in #15, but Liam makes a good point that it's not very beginner friendly for a boilerplate, and he would prefer a fix like #14.
Let's see what the community thinks is the best option.
imliam commentedon May 8, 2020
@pktharindu FYI
I absolutely prefer using keys in a real application that needs full translations, especially combined with a tool like i18n-ally to see the real values inline with code lens, which mitigates the issue of not seeing the real string somewhat.
However, I don't think that it's a very friendly way for most people, especially as we can't force tooling like that, as the majority of apps don't even need internationalisation support. The simpler approach of using the fill string is indeed less flexible, but in my opinion it's so much easier for people to understand exactly what it is, which I think is important in a preset.
What're people's thoughts on this?
Wulfheart commentedon May 8, 2020
@imliam In my opinion it should become clear when you read the english strings.
However is it a possibility to add both as a option? As far as I know the
php artisan ui
does support options.pktharindu commentedon May 8, 2020
@Wulfheart, I'm really sorry I didn't notice this issue sooner. 😬🙏
I too prefer using translation keys for apps that need full translations, but IMO most of the apps won't need it. Adding translation keys like this adds an overhead of a translation file and makes it a bit harder to understand for beginners. But I guess ultimately it is up to the authors and community to decide.
Again, sorry about not noticing this sooner!
Wulfheart commentedon May 8, 2020
No problem @pktharindu. This way I could post a meme. 🙈
imliam commentedon May 8, 2020
@Wulfheart I'm not sure how we could do that cleanly without just outright duplicating all the views, any ideas?
Wulfheart commentedon May 8, 2020
@imliam Is it possible to run some calculations when running the
php artisan ui
-command? If yes the corresponding key could be compiled just then.danharrin commentedon May 8, 2020
That would be my preferred option.
By default, have the key-based translation strings in the views.
We then have a flag in the UI command that is able to swap these out for the translated versions.
Thoughts @Wulfheart @imliam?
Wulfheart commentedon May 8, 2020
Like it. 👍🏻
Do you know if such a “compile” option exists?
imliam commentedon May 8, 2020
I'd prefer it the other way around myself (the full strings by default because it's easier for people to understand, swapping out to the keys for people that actually want to translate stuff.
We can do whatever custom logic is needed - see the
src
directory. The service provider can register whatever extra flags it needs to call any custom logic. Right now the most we're doing is usingstr_replace()
on a couple of files, but should be possible to replace all these strings in a loop I guessWulfheart commentedon May 8, 2020
In this case a lookup-array should be sufficient. The only caveat I can see is that this array has to stay up to date with the lang files.
danharrin commentedon May 8, 2020
Can we not
array_merge
and write to the existing lang files instead of overwriting them?10 remaining items