Radicle v2.2.0 string translations in directory "./app" not written in ./resources/lang/radicle.pot

radicle
,
1

Hi Roots,

I noticed any string translations used for i18n localization are not working in the ./app directory. All other --include="app,config,resources,public/dist/js" inside the ./package.json are working and are written inside the ./resources/lang/radicle.pot.

Directory app

It seems the wp i18n make-pot can’t scan the ./app directory since none of the string translations like __(‘My example string‘, 'radicle'); are saved in the radicle.pot.

Usages in x-components

I also found the string translations won’t be saved to the radicle.pot when you pass a string translation as prop attribute to the Component.

// .resources/views/partials/content-none.blade.php

<x-no-results
    :title="__('My title is not written inside the radicle.pot file.', 'radicle')"
    :text="__('The content-none.blade.php gets scanned but these component constructor prop attributes are not inside the radicle.pot file.', 'radicle')"
/>

<p>{{ __('This a string translation I can translate.', 'radicle') }}</p>

I assume it’s because the Component runs inside the ./app directory at ./app/View/Components/NoResult.php.

<?php

namespace App\View\Components;

use Closure;
use Illuminate\Contracts\View\View;
use Illuminate\View\Component;

class NoResults extends Component
{
    /**
     * Create a new component instance.
     */
    public function __construct(
        public ?string $title = null,
        public ?string $subtitle = null,
    ) {
        //
    }

    /**
     * Get the view / contents that represent the component.
     */
    public function render(): View|Closure|string
    {
        return view('components.no-results');
    }
}

Even though the x-no-results is inside .resources/ the string translations won’t get recognized once they are inside the x-component prop. So the localization is not working in ./app & x-component props. Do you have any suggestions on how to resolve these issues?

Looking forward to your insights.

Best regards,
Lex

2

Hi Roots,

I was wondering if you know the reason why these string translations as described are not coming in the radicle.pot?

Looking forward to your insights or fix.

Best regards,
Lex

3

Sorry for the late response! Can you try this?

  "scripts": {
    "build": "vite build",
    "dev": "vite",
    "translate": "npm run translate:pot && npm run translate:update",
    "translate:pot": "wp i18n make-pot app ./resources/lang/radicle.pot --domain=radicle --ignore-domain && wp i18n make-pot resources ./resources/lang/radicle.pot --domain=radicle --ignore-domain --merge=./resources/lang/radicle.pot && wp i18n make-pot config ./resources/lang/radicle.pot --domain=radicle --ignore-domain --merge=./resources/lang/radicle.pot",
    "translate:update": "for file in ./resources/lang/*.po; do wp i18n update-po ./resources/lang/radicle.pot $file; done",
    "translate:compile": "npm run translate:mo && npm run translate:js",
    "translate:js": "wp i18n make-json ./resources/lang --pretty-print",
    "translate:mo": "wp i18n make-mo ./resources/lang ./resources/lang"
  },

The --include flag doesn’t work correctly when the source is . in Radicle’s project structure

This workaround runs make-pot on each directory separately and merges them

Regarding component prop attributes like :title="__('...', 'radicle')" , that’s a separate parser limitation

The workaround is to extract translations to variables:

@php
    $title = __('My title', 'radicle');
@endphp

<x-no-results :title="$title" />
4

Hi Ben,

Thank you for the response. I have tested your changes on the “translate:pot” but unfortunately without success. The translatable strings that are put directly into the x-component props are not showing up in the pot file.

@php(__('Success: I can translate this standalone string.', 'radicle'))
<x-alert type="warning" class="my-6" :message="__('Failed: I can\'t translate this string directly in a component prop!', 'radicle')">
    {{ __('Success: I can translate this $slot.', 'radicle') }}
</x-alert>

I like to see we came up with the same workaround :slight_smile:. For now we stick to this workaround. Is this something you will implement as fix later or is it currently not on your patch list?

Best regards,
Lex

5

Submitted an upstream PR here: