boxblinkracer / phpunuhi Goto Github PK

it would be good to have a command to find translation files that are not yet added to the config.
maybe with regex and/or excludedDirectory mode?

it would be great to have the option to specify a basePath for all locales

<locales basePath="/my-path/translations">
    <locale name="en">%basePath%/en.ini</locale>
    <locale name="de">%basePath%/de.ini</locale>
</locales>

it would be great if keys could be migrated or fixed,
e.g. from pascal to camel case and so on

Hi there,

first of all, thanks for this nice framework and sorry for the wall of text.
I have looked at this specifically with a focus on Shopware 6 entities and have a few questions/remarks.

There are problems with null-values when using the "shopware6" format . However, these can always occur, e.g. if a product only have minimal data yet. From my point of view, this is a bug, or am I missing something?

Fatal error: Uncaught TypeError: PHPUnuhi\Bundles\Storage\Shopware6\Service\TranslationLoader::isBinary(): Argument #1 ($str) must be of type string, null given, called in /app/vendor/boxblinkracer/phpunuhi/src/Bundles/Storage/Shopware6/Service/TranslationLoader.php on line 167 and defined in /app/vendor/boxblinkracer/phpunuhi/src/Traits/BinaryTrait.php:38

I haven't tested it extensively yet, but it seems to be sufficient to convert null values to empty strings at this point.

If the "translate" command is called with the option "--source", an attempt is still made to translate missing translations of the source language itself. However, this will always fail in this case as $existingData = $set->findAnyExistingTranslation($currentID, $sourceLocale); will throw a TranslationNotFoundException.

If the source language is not skipped in the loop, if a text is missing you get an error message for each of the other languages plus additionally for the source language. I think this is unnecessary and the source language could be skipped in this case.

My intended use is mainly related to the translation of missing texts from Shopware entities. In my opinion, however, the logic here should be able to deviate from the usual snippets.

Using the product entity as an example:
Based on the table structure, there are already fixed fields that Shopware supplies, but it may be that some of them are not needed in a project. Others could be optional and only be filled for some products.

As long as something is not available in the main language of the shop, it should not be considered "missing" in my case.

I would like the following behavior for shopware entities when the "translate" command is executed with option "--source":

If a value is missing in the "--source" language e.g. "description" skip it.
Otherwise try to translate if for all other languages where a translation is missing.

As far as I could tell after trying around a bit, this does not seem to be possible at the moment, as the processing is always independent of the source (storage) and this special case for Shopware entities can therefore not be implemented without further ado.

The framework could certainly be extended in this regard, but I am unsure whether its a good idea to bend the framework in this direction, so I wanted to ask whats your opinion is about this use-case.

Sometimes you are forced to have specific keys written in a specific case style although you just dont like it.

in that case you dont want to break your rules
but rather add some kind of "allow list" for some keys to let them be as they are :)

The php vendor/bin/phpunuhi validate:all command validates all translations. Is there any possibility of ignoring or suppressing some snippets from this check?

Several translations have been intentionally left blank. For example shopBE.general.socials.pinterestLink has no translation for en-GB but has a translation for it-IT.

add "entity" for snippets in the database

should be the same sw6 storage format, only with a fake "entity" snippet that behaves a bit different

not necessary but good idea

comparing 2 storage formats

this could help to figure out if imports worked from e.g. JSON files in to a Shopware database

2 features
a) structure compare
b) content compare -> helps to verify if something changed

the tricky thing with XML storages is that there needs to be some kind of mapping or xsd,
because xml structures are (always) different.

anyone an idea?

it would be great to get custom (optional) reports on commands that change things
such as fix:structure or translate

then it would be possible to see what has been done afterwards

Hi,

In Shopware 6, in addition to the translations of various entities (usually in the [...]_translation table), there is also the option of assigning categories and products layouts from the shopping experiences area. As soon as this has been done, you have the option of storing various other fields with content in the respective language in each category and each product. This data is stored for categories, for example, in the category_translation table in the slot_config field as json.

Here we have the challenge that this data, preferably in CSV format, should also be sent to an external translator.

It would therefore be very helpful if there was a way to export and import this data with PHPUnuhi.

validation reports should also show the line number for storage formats that are based on files

it would be great to define a pattern for the key. like foo-bar or fooBar.
this could be defined as regex on storages

Hi there

Update: the initial question is no longer relevant now that we've changed the title in this issue

{
    "An unknown error occurred.": "Een onbekende fout is opgetreden.",
    "Searching...": "Zoeken..."
}

{
    "An unknown error occurred": {
        "": "Een onbekende fout is opgetreden."
    },
    "Searching": {
        "": {
            "": {
                "": "Zoeken..."
            }
        }
    }
}

We currently have the problem that we have a translation for Country, like USA or Germany, and Country, the style or synonyme for Countryside. This causes problems with the duplicate check as it fails only in the english translations not i.e. the german as we have Land and Country there. As they mean something different by context and are spelled differently in german we cannot aggregate them to one key. This is probably not the only word and langauge where this can cause problems.

For now, which fixes this problem in our case, the filter logic for the key would be suffice so I've implemented it for yaml: #35

But in any other case this maybe would not be enough so I think we need to think about another possibility to fix this issue. My first idea would be to have a whitelist option for the duplicate content rule. Probably you also need to make it language specific as you want Country twice in english but only once in german.

Would that be a viable solution or are there any better ones? I'm happy to implement it but wanted your feedback first.

add json report option such as php cs fixer

at the moment any existing language will be used as "source" for translation service
it would be good to define a single one

It would be good to have the option to create separate configuration files
and import those in the main file

<translations>

     <import file="....."/>
     <import file="....."/>

    <set name..../>

</translations>

add option to add custom services at runtime. custom translators, storages and more

It would be great if the locale name could be used
as placeholder in the file path

sometimes folders AND the file name contain the locale, and this would be better for maintaining things

        <locales>
            <locale name="en-GB">./{locale}/xxxx/{locale}.json</locale>
        </locales>

I would like to configure all my translation sets in sub-files and then import them into a main file. However, no extra set should be configured in the main file. This is currently not possible as the “translations” node is required.

Hi guys

I've just started testing this package on my system (macOS) and noticed I can't run vendor/bin/phpunuhi, I get:

/usr/bin/php: bad interpreter: No such file or directory

This is because the shebang at the top of the bin script is hardcoded instead of trying to find the correct php binary from the environment.

So the line:

#!/usr/bin/php

Should be replaced with:

#!/usr/bin/env php

This is also how other php packages do this, for example:

• https://github.com/sebastianbergmann/phpunit/blob/a5813fb2fc2a69d86fefe4ec2659a00cc3d4c590/phpunit#L1
• https://github.com/composer/composer/blob/ecb69eaa4aec3c2bd866d17ee7a46e684dc16f71/bin/composer#L1
• https://github.com/phpstan/phpstan/blob/7da13f74db97ab5afb1d9d28df4d7c5b9bdca46f/phpstan#L1
• ...

Thanks!

it would be great to have a

"*" wildcard that merges all found files

        <locales>
            <locale name="en-dev">./**/*.json</locale>
        </locales>

this helps if maaaany json files exist.
Keys and their neting path need to be unique anyway..(if one wants to use this feature)
so a recursive merge before comparing results should be fine.

only filenames cannot be displayed in that case

it would be good to only export empty translations
and just skip existing ones

this would be easier for people who add the last missing ones

please double check that an import only overwrites the provided one...so that nothing is lost accidentally

This part always prepends the working directory to the configuration path.

This way I can't provide an absolute path which is sometimes easier to do.

There might be a use case where you want to remove keys from all files

so maybe a separate command
or something like fix:structure but only for destructive purposes

or maybe fix:structure with a provided base-locale file as structure-template?

If you have translation markers e.g. The name of the product is %productName%.
The placeholder %productName% should be protected from translation via translation services.

Hi,

This is a feature request for non-snippet translations. Currently in Shopware 6 (6.6) not all translations are editable with the use of snippets. The following three sections are connected to the frontend for customers to see by default.

• For the State Machine they aren't even editable in the admin.
  Located in the state_machine_state_translation table
• The sorting options can be edited in the admin: Settings->Shop->Products
  Located in the product_sorting_translation table
• The salutations can be edited in the admin: Settings->Shop->Salutations
  Located in the salutation_translation table

There are more translations not using snippets, tables with [...]_translation. But those are data driven for example the categories and shopping experiences.

its not always possible
but in theory a folder of twig files can be used to search for unused translations

When using MJLM templates with snippets, snippets are not detected because a MJML scanner is currently not supported.
This can be very useful when using the Shopware plugin FroshPlatformTemplateMail