Skip to content

Adding support for L10n #12

Open
Open
@Wulfheart

Description

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

Activity

Wulfheart

Wulfheart commented on May 8, 2020

@Wulfheart
ContributorAuthor

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'.
grafik

danharrin

danharrin commented on May 8, 2020

@danharrin
Member

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

imliam commented on May 8, 2020

@imliam
Contributor

@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

Wulfheart commented on May 8, 2020

@Wulfheart
ContributorAuthor

@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

pktharindu commented on May 8, 2020

@pktharindu
Contributor

@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

Wulfheart commented on May 8, 2020

@Wulfheart
ContributorAuthor

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

imliam

imliam commented on May 8, 2020

@imliam
Contributor

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

Wulfheart commented on May 8, 2020

@Wulfheart
ContributorAuthor

@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

danharrin commented on May 8, 2020

@danharrin
Member

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

Wulfheart commented on May 8, 2020

@Wulfheart
ContributorAuthor

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

imliam

imliam commented on May 8, 2020

@imliam
Contributor

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

Wulfheart commented on May 8, 2020

@Wulfheart
ContributorAuthor

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

danharrin commented on May 8, 2020

@danharrin
Member

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

10 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      Adding support for L10n · Issue #12 · laravel-frontend-presets/tall