Externer I18n Gebietsschemapfad (AWS)

Question

Ich habe ein Datenbank-basiertes Übersetzungssystem für meine Rails-App, das großartig funktioniert, außer dass es offensichtlich eine Menge Anfragen an die Datenbank sendet. Ich kann den Cache nur für eine bestimmte Anzahl von Anfragen verwenden, aber eine praktikable Option für mich ist, die Übersetzungstabelle in eine YAML-Datei zu exportieren, die vom System gelesen werden kann.

Das Problem, das ich habe, ist, dass meine App auf Heroku ist und Sie nicht in dieses Dateisystem schreiben können, muss ich AWS (mit Carrierwave) verwenden, um die Locale-Dateien zu speichern. Ich kann nach AWS schreiben, aber ich kann meine Rails-App nicht dazu bringen, die Locale-Dateien von meinem AWS-Speicher zu lesen.

Ich habe die folgende Einstellung versucht (was nur Versuch und Irrtum ist), aber es funktioniert nicht.

application.rb

config.i18n.load_path += Dir[Rails.root.join('my', 'locales', '*.{rb,yml}').to_s] 
config.i18n.load_path += Dir["https://s3-eu-west-1.amazonaws.com/myapp/locales/", '*.{rb,yml}'.to_s] 
config.i18n.available_locales = [:en, :se] 

Edit: Mein aktueller (langweilig) Workflow ist es, alle Übersetzungen in der Datenbank zu erstellen (Datenbank Übersetzungen verwendet, ist ein absoluter Muss für mich btw). Dann exportiere ich die Tabelle nach Yaml in meinen AWS-Speicher. Von dort lade ich die Locale-Dateien in meine lokale App und in den Locale-Ordner. Ich lade alles wieder auf Heroku hoch. Alles nur, weil ich nicht in das Heroku-Dateisystem schreiben kann.

Wie kann ich meine App so einrichten, dass die Locale-Dateien (z. B. https://s3-eu-west-1.amazonaws.com/myapp/locales/en.yml) von dieser externen Quelle gelesen werden? Ist es überhaupt möglich? Wenn nicht, gibt es einen Workaround?

Answer 1

Ich glaube, Sie können keine externen Übersetzungen direkt mit 'Dir' hinzufügen. Weil es lokal funktioniert. Um das Problem zu umgehen, können Sie Ihre externe Datei auf das lokale System laden und dann mit Dir auf I18n auf dieselbe Weise zugreifen. Wie auch immer, die untere Seite, um Änderungen in der externen Datei zu laden, müssen Sie immer Ihren Produktionsserver neu starten. Es ist also dasselbe wie das Speichern von Datei Localy.

Answer 2

In den Sinn kommt es an, einen Cache für Ihre Datenbank zu implementieren (Sie müssen also keine YML-Dateien verwenden). Erstens, wenn auf einen Schlüssel zugegriffen wurde, wird das Ergebnis zwischengespeichert und beim zweiten Nachschlagen wird der i18n den zwischengespeicherten Wert verwenden.

I18n::Backend::ActiveRecord.send(:include, I18n::Backend::Cache) 
I18n.cache_store = ActiveSupport::Cache.lookup_store(:memory_store) # or whatever store you prefer 

Eine Möglichkeit wäre, zu gehen mit dem Cache zum Aufwärmen: I18n.cache_store.write({"en.some.key" => "value"}). Ich denke, es sollte nicht zu schwer sein, es aus der Datenbank zu füllen.

Das Problem liegt vor, wenn Sie den Cache ungültig machen möchten. Sie müssten Ihr eigenes Backend für activerecord erstellen. Here ist die Speichermethode. Sie müssten ein neues Back-End-Modul erstellen, das den Cache löscht und neu auffüllt.

def store_translations(locale, data, options = {}) 
    I18n.cache_store.clear 
    super 
    I18n.cache_store.write(#cached_values) 
end 

Wenn der Cache sehr groß würden Sie eine intelligentere store_translation Methode implementieren müssen, dass verwaltet die spezifischen Übersetzung.

Dies ist ein Stück von Sessel-Engineering, aber mit einigem Aufwand denke ich, dass Sie in der Lage sein würden, einen robusten Speicher für Ihre activecord Übersetzungen zu erstellen.