customizable locale dictionary

[ariaieboy]

hello everyone
I had a problem with the Persian translation of this project, which was inconsistency in the translations.

For example, some keywords like password have multiple translations in Persian and each person can translate it to a specific word in Persian.

I plan to create a dictionary for Persian translation. so anyone who wants to help translate the keys has a guideline about selecting the correct translations for most used keywords so we have normalized translations across all of our Persian keys.

A good feature can be a customizable dictionary for these keywords so anyone could change the most used keywords based on the business guideline or the culture of their application.

[andrey-helldar]

I think that adding a dictionary of dialects is inappropriate because it will be difficult to maintain. Instead we can create new localizations like fa_Pes and fa_Prs. This is exactly what we have done for the German, Portuguese, Serbian, Uzbek and Chinese languages:

• de
• de_CH
• pt
• pt_BR
• sr_Cyrl
• sr_Latn
• sr_Latn_ME
• uz_Cyrl
• uz_Latn
• zh_CN
• zh_HK
• zh_TW

Thus, all the necessary options can be installed in the application.

And if in the final application you need to explicitly use only one localization, for example, fa, saving the necessary dialect in it, then you can use the alias setting in the installer:

'aliases' => [
    'fa_Pes' => 'fa',
],

https://github.com/Laravel-Lang/publisher/blob/main/config/public.php#L50-L54

And the project will have three available localizations:

• fa
• fa_Pes
• fa_Prs

https://en.wikipedia.org/wiki/ISO_639_macrolanguage#fas

What do you think?

[ariaieboy]

for now, if I found some free time in my schedule I am gonna start normalizing the translation for Persian and after that, I will look into this again

[andrey-helldar]

In this case, in the near future I will implement this structure in the update scripts, as well as the publisher.

The only thing I'm not sure is that the word "slang" should be used. In my opinion, "jargon" is better suited. But even here I'm not sure. Do you have any thoughts on this?

[andrey-helldar]

I figured it out. The structure does not need to be changed.

Current structure:

locales/
  af/
    _excludes.json
    json-inline.json
    json.json
    php-inline.json
    php.json

Next structure:

locales/
  af/
    _excludes.json
    json-inline.json
    json.json
    php-inline.json
    php.json
    variations/
      foo/
        json-inline.json
        json.json
        php-inline.json
        php.json

[andrey-helldar]

I will be able to add support for this functionality to the publisher only in January. Before that, I need to finish another project.

[andrey-helldar]

@ariaieboy, hey! I thought about various possible options for improving the logic and came to the conclusion that the best solution would be to create a new localization.

This is due to the fact that the publisher does not know anything about the packages connected to it. Thus, the publisher will not know about the available localization options not only in the Lang project, but also in any others that our team has nothing to do with (we even created a template for this).

Thus, each developer will have to manually go into the files of the project he is installing, see if there are options in it, and only after that configure the configuration file. It's complicated.

Therefore, I suggest creating new localizations with a variance mark. It will be right.