Translatable names & descriptions

[boryn]

As now it's very often necessary to create multilanguage systems, I opt for translatable names & descriptions for plans, features and subscriptions. I'd suggest using https://github.com/spatie/laravel-translatable which is very easy to implement.

[bpuig]

The issue here, is that, for example, I like and usually use (https://github.com/Astrotomic/laravel-translatable)[https://github.com/Astrotomic/laravel-translatable]. And now I (and more people using others) if I use spatie's, would have 2 translation packages in my project. Shouldn't we leave it to personal preferences and everyone use what they use in their projects? Maybe you can do your own "extension", laravel-subby-translations 😃 and keep it modular Since there are many packages, who knows what is everyone using...

[boryn]

Actually someone can use Laravel built-in translations and refer to let's say subby.subscription.main.name / subby.subscription.main.description / subby.features.social_profiles.name substituting the tag field. What do you think? This hint could be worth mentioning in the docs as people would scratch their heads how to handle it.

[bpuig]

I don't see built-in because subscription name is dynamic and you are using fixed translations, you'd defeat part of the purpose and functionality of the subscription model. A third party package would be better.

[boryn]

Why do you consider subscription name to by dynamic? It's me who gives it a tag like 'main' or 'primary'. And the same way I know the tags of plans or features.

Having subby.php like this:

<?php

return [
    'plans' => [
        'basic' => [
            'name' => 'Basic Plan',
            'description'    => 'For small businesses',
        ],
        'middle' => [
            'name'        => 'Mid Plan',
            'description' => 'For medium businesses',
        ],
    ],

    'features' => [
        'social_profiles'  => [
            'name'        => 'Your number of social profiles',
            'description' => 'Tells how many profiles you may use per month',
        ],
        'analytics' => [
            'name'        => 'Analytics',
            'description' => 'Access to the Analytics module',
        ],
    ],
];

I'm perfectly fine to use trans('subby.features.analytics.description') and if I need to use it on a variable base I can do: trans("subby.features.$featureTag.description");.

Just after my above considerations I think it's not necessary to implement any third party translation package at all :)

[bpuig]

Why do you consider subscription name to by dynamic? Sorry, I was thinking about tags...

I see your point, but I also see that is something more close to your use case and package is compatible with that. So you can do your information retrieval before creation and then set it into the creation variables.