Gdzie trzymac info o lokalizacji (i18n/l10n)?

Potrzebna pomoc
1

Przygladnalem sie Globalize i musze powiedziec ok - dziala, ale … bardziej przemowilo do mnie lekkie rozwiazanie opisane tutaj: Ruby on Rails i18n revisited - zwlaszcza, ze instalacja jest banalna: script/plugin install localization

A teraz pytanie: Gdzie trzymac informacje o jezyku (lub ogolniej jakakolwiek informacje z requestu na request)?

  1. Cookies
    Bezproblemowo.
class ApplicationController < ActionController::Base
  before_filter :set_locale
  def set_locale
      Localization.lang = cookies[:_locale]      
  end 
end

Dodatkowo plus, ze jezeli klient powroci na strone a cookie nie wygasnie to dostanie poprzednie ustawienia. No i wszystkie sprawy typu remember me w ten sposob dzialaja. Minus oczywiscie jak ktos ma wylaczone cookies. No i co zrobic gdy aplikacjia ma tez obslugiwac urzadzenia mobilne?

  1. Session
    Bezproblemowo, ale po co session (jesli chodzi o jave to zostalem nauczony, ze stworzenie sesji jest kosztowne i nalezy dopoki sie da bez niej obywac). Z drugiej strony skoro juz istnieje … ale sesja jest w Rails trzymana w pliku, w bazie albo na serwerze DRb i czy dostawanie sie tam co request po stringa ma sens? Jezeli sesja juz istnieje i cos w niej juz trzymam to czy jest zawsze ladowana w calosci czy cos w rodzaju lazy czyli na zadanie?

Tak przy okazji to znalazlem porownanie Session Container Performance in Ruby on Rails i zastanawia mnie wydajnosc PStore gdy systemem plikow jest reiserfs - czy ktos zna odpowiedz?

  1. Jako parametr i pomieszac z routes np. /pl/controller/action/
    Troche przekombinowane. Czy jest sens skoro sesje w Rails i tak sa cookie-based?
    Tutaj dochodzi jeszcze sprawa ajaxa: link_to_remote i pobieranie lokalizowanych danych. Czy nie bedzie z tym problemu?

  2. Pole hidden?
    w Tapestry mozna poprzez DataSqueezer serializowac prostsze obiekty do query parameter lub pola hidden i unikac HttpSession w ten sposob. Nigdy tego nie stosowalem ale moge sobie wyobrazic sytuacje gdy ma to sens.

Ktore podejscie jest optymalne pod wzgledem wydajnosci i/lub uniwersalnosci? Ja sklaniam sie do Cookies.
Bylbym wdzieczny za opinie bardziej oswieconych forumowiczow :slight_smile:

2

ja bym trzymaÂł w cookie.

a co do porĂłwnania wydajnoÂści to jakaÂś strasznie archaiczna wersja…

ja teÂż stojĂŞ przed problemem lokalizacji i jakoÂś chyba nie do koĂąca rozumiem proponowane rozwiÂązania. czy nadajÂą siĂŞ one takÂże do lokalizowania tekstĂłw wysyÂłanych przez kontroler? np. flashy?

3

Globalize to jest zbyt kompleksowe rozwiazanie jak na moj gust - na poczatek wygenerowalo mi 3 tabele ze wszystkimi jezykami swiata :slight_smile: - Przyjrzalem sie tylko pobieznie. Co do opisywanego rozwiazania to TAK - wszystko co znajdzie sie w metodzie _() ulega lokalizacji (kontroler/helper/model). Co prawda proponuje na koniec tej metody dorzucic fallback do defaultowej lokalizacji czyli aktualnego stringa w _().

def self._(string_to_localize, *args)
...
rescue NoMethodError
   string_to_localize
end
4

a tak, to widziaÂłem, tym siĂŞ chwalili (wszystkimi jĂŞzykami Âświata), myÂślĂŞ, Âże to trochĂŞ overkill, mieĂŚ wiĂŞksza tabelĂŞ z jĂŞzykami niÂż z danymi.

dziêki za podpowiedŸ, póŸno by³o. no to siê biorê za lokalizacjê.