Informal translations

[obrunsmann]

Feature description

We are working on products in which we use the informal form of address, which I believe is very widespread in the SaaS sector in Germany.

I would like to contribute to adapting the translations accordingly, perhaps there is an option to add 'de_informal' in addition to 'de', for example, so that you can choose which form of address you want to use during installation?

Is that of interest?

[andrey-helldar]

Hi!

Is there any localization code for this form of language? Right now localization code must comply with ISO-15897 and ISO-639-1.

If necessary, we can easily move away from ISO standards. All that remains is to determine in which direction.

@sotten, what do you think?

[obrunsmann]

Afaik there is no dedicated language/locale code for formal/informal language.. this is also a common problem like currently on openAI to tell them to use informal form 😅

Maybe we could also solve this by modifying the publisher code to prompt the user if he wishes to use formal or informal form when publishing lang files?

[andrey-helldar]

@obrunsmann, yes, this will be regulated by an option in the settings.

There will remain the question of filling it in.

On a side note, this is not the first time people have asked about the possibility of adding an informal translation.

@Laravel-Lang/laravel-lang, what do you think if we add the ability to use informal translation for all localizations?

For example:

de
   _excludes.json
   _informal.json
   json-informal-inline.json  <
   json-informal.json         <
   json-inline.json
   json.json
   php-informal-inline.json   <
   php-informal.json          <
   php-inline.json
   php.json

There are also some keys, such as country names, for which an informal translation is not needed. In this case the work with keys will be in two stages: translation stage and installation stage.

At the translations stage, I suggest adding a new conditional-system file _informal.json, which will contain a list of those keys that do not need to be translated to the informal form.

At the installation stage, the publisher will look for the necessary keys and if they are not in the informal version, it will take them from the formal one.

And if the language does not require an informal form in principle, then the _informal.json file will not just have an array inside, but an object. For example:

{
    "enabled": false,
    "except": []
}

This will avoid creating translation files when generating them.

[luisprmat]

I like the idea, in Spanish, more regionalized languages ​​that do not have ISO as such are also used in many applications, in Bogotá or the Colombian Caribbean the language differs slightly from that spoken in Madrid (Spain)

[andrey-helldar]

I think I will do this functionality at my leisure. This is the third or fourth time in the last year that people have asked about informal translation.

[chillbram]

I would like to note that informal Dutch (T) is the most the commonly used version online and in general speech (more so in nl_NL than nl_BE). So currently, all the translations are already in the informal form as it's the default most people would want in their applications. A setting in your proposed _informal.json which defines the default for a language could prevent a lot of unnecessary configuration for most users.

These language forms probably open a new can of worms, but always appreciate your efforts in creating order in the madness of natural languages @andrey-helldar :)

[andrey-helldar]

@chillbram, thank you)

Yes, in the case of Dutch, you could add a _informal.json file with the option and then no *-informal-* files would be created for that language.

{
    "enabled": false
}

Thus, choosing the option to set an informal language will not play any role. And the only translation of phrases will be installed in the application.

The other day there was a discussion on Ukrainian localization (Laravel-Lang/lang#3610), where the informal form is also more used at the state level and there is no need to create another "informal" translation.

[chillbram]

Oh, but I do see the value in a formal version for Dutch. There are definitely still some companies and sectors which prefer it, although I don't know if we should necessarily cater for them as even the central government has been using informal forms for quite some time. Maybe just something to consider then.

[andrey-helldar]

In this case, I see two options for informal translations: one true informal, where communication is done as with a friend, and the other used at the state level.

I could be wrong, but I suggest that in such a situation the informal language should be used as the official translation for languages like Dutch and Ukrainian, but the conversation "as with a friend" should be used as the "informal" one.

Thus, if the developer activates the informal mode in the publisher settings, then all localizations will be set "as for friends", and if there are no such files or they are turned off by the localization settings, then the main translation will be used.

And if you deactivate the informal translation, then the main translation will be used for all languages. That is, for such languages as Dutch and Ukrainian, informal localizations will be used.

The only thing is that I have a feeling that there is a mistake in this scheme, but I can't figure out where it is...

[chillbram]

Yeah that sounds great! That would also be easily adjustable to new complexities when they inevitably arrive. You probably don't want to have all these files for each language in the folder. There's no reason for languages without these distinctions to gain 4x files; that might also confuse new contributors

[andrey-helldar]

On the one hand this is true, but on the other hand, if we create a separate project, it will either be a lot of repositories like laravel-lang/common-default, laravel-lang/common-informal, etc., or we will have to install each package separately and there will be no point in common. But then we will lose the ability to choose the right translations for specific localizations, because each package will try to install its own and the one that will be loaded last, according to array_merge rules, and will save its changes.

So I think it's right to keep the options for one translation in one place.

[chillbram]

I was thinking more of culling individual files not used by a language (e.g. German would only need default and informal files), but I concede that that would probably require quite a bit of effort trying to get the various scripts to work nicely with that.

[andrey-helldar]

I understand. To do this, a “system” file _styles.json will be created, which will store the disabled key. Thus, if the German language contained only the default and informal styles, then its file would look like this:

{
   "disabled": ["formal", "personal"],
}

And the files will look like this:

de
   _excludes.json
   _styles.json

   json-default-inline.json
   json-default.json
   json-informal-inline.json
   json-informal.json
   
   php-default-inline.json
   php-default.json
   php-informal-inline.json
   php-informal.json

[andrey-helldar]

I've been thinking that it's better not to turn off unnecessary language forms in every language, but instead to turn them on in certain languages.

For example:

de
   _excludes.json
   _styles.json

   json-default-inline.json
   json-default.json
   json-informal-inline.json
   json-informal.json
   
   php-default-inline.json
   php-default.json
   php-informal-inline.json
   php-informal.json

fr
   _excludes.json

   json-default-inline.json
   json-default.json
   json-personal-inline.json
   json-personal.json
   
   php-default-inline.json
   php-default.json
   php-personal-inline.json
   php-personal.json

vi
   json-default-inline.json
   json-default.json
   
   php-default-inline.json
   php-default.json

// de/_styles.json
{
   "enabled": ["informal"],
}

// fr/_styles.json
{
   "enabled": ["personal"],
}

// vi/_styles.json
not exists

This will avoid creating unnecessary files.

[makowskid]

But we're opening an endless can of worms here of local dialects :)

[andrey-helldar]

That's right