class Lang
{
/** @var LangResolverInterface */
protected $langResolver;
/** @var string */
protected $lang;
/**
* Lang constructor.
*
* @param LangResolverInterface $langResolver
*/
public function __construct(LangResolverInterface $langResolver)
{
$this->langResolver = $langResolver;
$lang = $langResolver->getDefaultLang();
}
/**
* @param string $lang
*
* @return $this
*/
public function changeLang($lang)
{
$resolvedLang = $this->langResolver->resolve($lang);
if (null === $resolvedLang) {
throw
new \InvalidArgumentException
(sprintf('Lang "%s" is not supported.', $lang)); }
$this->lang = $resolvedLang;
return $this;
}
}
Możesz coś podobnego przekminić, wydziel logikę odpowiedzialną za "sprawdzenie" języka gdzieś na zewnątrz, dispatchuj event na zmianę języka.
Opcji są miliony
Cytat
gdy użytkownik ma ciasteczko to odczytujemy zapisany w nim język i zapisujemy dodatkowo do zmiennej sesyjnej
Wywal to do osobnego obiektu, który w razie potrzeby odpali
->setLang($lang);
na klasie
Lang, z założenia
Lang nie musi wiedzieć kto, skąd i po co zmienia język, ma to tylko ogarnąć po swojej stronie i tyle (plus ewentualnie powiadomić jakimś eventem że zmiana miała miejsce)
Cytat
gdy mamy zmienną, to znaczy że użytkownik chce zmienić obecny język
Może abstrakcja, ale... co jeżeli pewna część kontentu będzie w innym języku? W teorii muszę utworzyć nową instancję klasy
Lang po to, żeby w tym momencie ten język zmienić?
Cytat
return $this->lang.'.lang.php';
Może potraktuj tłumaczenia (zakładam strukturę key=>value) raczej jako config? W sensie *.ini, *.yml, xml itd.
Dodatkowo, możesz napisać sobie coś w rodzaju
Translatora, co za tym idzie... mówić mu aby tłumaczył klucze na uprzednio załadowanej konfiguracji języka.
Do tego musisz oczywiście pamiętać o fallback'u - w momencie gdy dane tłumaczenie (klucz) nie istnieje.
P.S. taki troche Symfony-way