Adding support for L10n

[Wulfheart]

I noticed that everything is hardcoded text. I'm going to open a pull request with proper auth texts soon.

[Wulfheart]

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]

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]

@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]

@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]

@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]

No problem @pktharindu. This way I could post a meme. 🙈

[imliam]

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 not sure how we could do that cleanly without just outright duplicating all the views, any ideas?

[Wulfheart]

@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]

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]

Like it. 👍🏻
Do you know if such a “compile” option exists?

[imliam]

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

[Wulfheart]

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]

Can we not array_merge and write to the existing lang files instead of overwriting them?