Chcę zmusić nested set (jakiekolwiek, zwykłę, awesome, better …) aby translacje globalize posiadały inne sortowanie pozycji list na danym poziomie. Dążę do tego, aby lista (na drzewie) w każdym języku była posortowana alfabetycznie dla każdego języka z osoba. Zrobiłem więc forka globalize, dodałem możliwość dodawania pól integer do translacji (Tomash jeśli będzie to czytał, to właśnie pracuje nad testami), niestety w trakcie testów z różnymi gemami nested set okazało się, że pozycje left i right nadawane są tylko w momencie utworzenia rekordu a nie zapisu. Problem jest taki, że tworzenie tłumaczeń w globalize wymaga również zmiany aktualnego języka strony. Wykonuję pętlę po dostępnych języka, zapisuje pola tłumaczeń a następnie wykonuje metodę save. left i right nadawane jest tylko dla pierwszego tłumaczenia ponieważ wtedy rekord jest tworzony, rozwiązałem to poprzez wywołanie metody “set_default_left_and_right”. Niestety ta metoda przy utworzeniu kilku rekordów (wężłów) drzewa ustawia left na 1 i right 2 (za wyjatkiem pierwszego tłumaczenia, tam działa wszystko dobrze)
Przykład:
I18n.available_locales.each do |locale|
I18n.locale = locale
self.title = attrs["title_#{locale}"]
self.abbr = attrs["abbr_#{locale}"]
send(:set_default_left_and_right) unless left or right
save
end
Musiałbyś przeliczać drzewo po każdej edycji (przesortowaniu). A do tego awesome_nested_set ma zapytania po prostu biorące “oryginalne” left i right, bez szans dla globalize na przekazanie “przetłumaczonych” wartości.
Generalnie żeś pan sobie wymyślił ficzer
Co ja bym zrobił: poszedł stopień wyżej w drzewie, tworząc wyżej w hierarchii węzeł “locale”. W ten sposób totalnie odseparujesz oddzielne językowo sortowania i na dodatek nie będziesz musiał hakować globalize.
en
-- bike
-- car
pl
-- rower
-- samochód
de
-- auto
-- fahrrad
W pewnym projektcie wykorzystałem własny mechanizm tłumaczenia który działał na takiej zasadzie jak opisałem w pierwszym poście, teraz chciałem to wykorzystać w globalize. Tomash, twoje rozwiązanie jest jedną z możliwości, które kiedyś rozważałem, ale w takiej sytuacja trzeba zhakować nested set ponieważ główne gałęzie lokale trzeba będzie jakoś obsłużyć. Niestety z takiego rozwiązania nie byłem zadowolony. Przebadam awesome_nested_set i zobaczę może uda się je odpowiednio dostosować, jeśli się nie da to przerobi się gem specjalnie dla globalize.
Chyba znalazłem rozwiązanie tego problemu. Problem stanowi fakt, że w awesome nested set zapytania (lub części zapytań) sql są hardkodowane a nie używają mechanizmu railsów. Jest to szybsze niż active query interface ale za to mniej elastyczne.
Trzeba by gema zmodyfikować tak, żeby uwzględniał aktualne locale, naszczęście mamy do tego odpowiedni scope w globalize oraz wykonywać joina na tablicę z tłumaczeniami lub zakodować to w active query interface. Podziedzcie tylko co jest lepsze.
