Localization Support

[yassiNebeL]

trafficstars

I'm planning to use Collator core PHP classes, in conjunction with .env file for configuration, also once the Collator class is instantiated with a specific locale, there's no need to additionally call Locale::setDefault() method.

APP_LOCALE=en_US

use Dotenv\Dotenv;
use Collator;
use Locale;

class Localization {
    private Collator $collator;
    private array $translations = [];

    public function __construct() 
    {
        // Load environment variables from .env file
        $dotenv = Dotenv::createImmutable(__DIR__);
        $dotenv->load();

        // Retrieve locale from .env file
        $locale = getenv('APP_LOCALE') ?: 'en_US';
        
        // Create Collator instance with the retrieved locale
        $this->collator = new Collator($locale);
    }

    public function addTranslation(string $key, string $translation): void 
    {
        $this->translations[$key] = $translation;
    }

    public function translate(string $key): string 
    {
        return $this->translations[$key] ?? $key;
    }

    private function loadTranslations(): void 
    {
        $filePath = sprintf("path/to/language/files/%s.php", str_replace('-', '_', Locale::getDefault()));
        
        $this->messages = match (true) {
            file_exists($filePath) => include $filePath,
            default => [] // Fallback to empty array if file not found
        };
    }
}

Still in it's experimental phase, would love to add a discovery to pragmatically load messages based on locale, but I need to study the code regarding the Discovery location.

[yassiNebeL]

@brendt or @aidan-casey, would you please add this to Tempest 1.0 ?

[aidan-casey]

My take would be that we absolutely want locales, but that it doesn't need to hold up the release of v1. It should be able to be added as a non breaking change after release.

That's not to say don't work on it now, just that I don't think it needs to block v1 if it doesn't get completed.

If I could offer one suggestion, I'd move the locale setting to the app or maybe even its own config and load that. 🙂

[yassiNebeL]

My take would be that we absolutely want locales, but that it doesn't need to hold up the release of v1. It should be able to be added as a non breaking change after release.

That's not to say don't work on it now, just that I don't think it needs to block v1 if it doesn't get completed.

If I could offer one suggestion, I'd move the locale setting to the app or maybe even its own config and load that. 🙂

OK, feel free to close this issue as it is not planned yet.

Best regards!

[aidan-casey]

@yassiNebeL - I have no problem leaving this open and accepting a PR if you were planning on working on this.

[yassiNebeL]

I would have liked to disccuss the translation file format .yaml or .php etc. before performing a PR

Internationalization (i18n), is important not only for scalability but also for audience inclusivity.

[brendt]

Definitely .php 👍

I agree this is an important feature to have. Not for 1.0, but one of the minor releases afterwards.

[brendt]

Gonna close this one for now. Not planning on tackling this any time soon