Add docs for i18n
This commit is contained in:
@@ -15,6 +15,7 @@ SQLAlchemy-Utils provides custom data types and various utility functions for SQ
|
|||||||
aggregates
|
aggregates
|
||||||
observers
|
observers
|
||||||
decorators
|
decorators
|
||||||
|
internationalization
|
||||||
generic_relationship
|
generic_relationship
|
||||||
database_helpers
|
database_helpers
|
||||||
foreign_key_helpers
|
foreign_key_helpers
|
||||||
|
93
docs/internationalization.rst
Normal file
93
docs/internationalization.rst
Normal file
@@ -0,0 +1,93 @@
|
|||||||
|
Internationalization
|
||||||
|
====================
|
||||||
|
|
||||||
|
SQLAlchemy-Utils provides a way for modeling translatable models. Model is
|
||||||
|
translatable if one or more of its columns can be displayed in various languages.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
The implementation is currently highly PostgreSQL specific since it needs
|
||||||
|
a dict-compatible column type (PostgreSQL HSTORE and JSON are such types).
|
||||||
|
If you want database-agnostic way of modeling i18n see `SQLAlchemy-i18n`_.
|
||||||
|
|
||||||
|
|
||||||
|
TranslationHybrid vs SQLAlchemy-i18n
|
||||||
|
------------------------------------
|
||||||
|
|
||||||
|
Compared to SQLAlchemy-i18n the TranslationHybrid has the following pros and cons:
|
||||||
|
|
||||||
|
* Usually faster since no joins are needed for fetching the data
|
||||||
|
* Less magic
|
||||||
|
* Easier to understand data model
|
||||||
|
* Only PostgreSQL supported for now
|
||||||
|
|
||||||
|
|
||||||
|
Quickstart
|
||||||
|
----------
|
||||||
|
|
||||||
|
Let's say we have an Article model with translatable name and content. First we
|
||||||
|
need to define the TranslationHybrid.
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
from sqlalchemy_utils import TranslationHybrid
|
||||||
|
|
||||||
|
|
||||||
|
# For testing purposes we define this as simple function which returns
|
||||||
|
# locale 'fi'. Usually you would define this function as something that
|
||||||
|
# returns the user's current locale.
|
||||||
|
def get_locale():
|
||||||
|
return 'fi'
|
||||||
|
|
||||||
|
|
||||||
|
translation_hybrid = TranslationHybrid(
|
||||||
|
current_locale=get_locale,
|
||||||
|
default_locale='en'
|
||||||
|
)
|
||||||
|
|
||||||
|
|
||||||
|
Then we can define the model.::
|
||||||
|
|
||||||
|
|
||||||
|
from sqlalchemy import *
|
||||||
|
from sqlalchemy.dialects.postgresql import HSTORE
|
||||||
|
|
||||||
|
|
||||||
|
class Article(Base):
|
||||||
|
__tablename__ = 'article'
|
||||||
|
|
||||||
|
id = Column(Integer, primary_key=True)
|
||||||
|
name_translations = Column(HSTORE)
|
||||||
|
content_translations = Column(HSTORE)
|
||||||
|
|
||||||
|
name = translation_hybrid(name_translations)
|
||||||
|
content = translation_hybrid(content_translations)
|
||||||
|
|
||||||
|
|
||||||
|
Now we can start using our translatable model. By assigning things to
|
||||||
|
translatable hybrids you are assigning them to the locale returned by the
|
||||||
|
`current_locale`.
|
||||||
|
::
|
||||||
|
|
||||||
|
|
||||||
|
article = Article(name='Joku artikkeli')
|
||||||
|
article.name_translations['fi'] # Joku artikkeli
|
||||||
|
article.name # Joku artikkeli
|
||||||
|
|
||||||
|
|
||||||
|
If you access the hybrid with a locale that doesn't exist the hybrid tries to
|
||||||
|
fetch a the locale returned by `default_locale`.
|
||||||
|
::
|
||||||
|
|
||||||
|
article = Article(name_translations={'en': 'Some article'})
|
||||||
|
article.name # Some article
|
||||||
|
article.name_translations['fi'] = 'Joku artikkeli'
|
||||||
|
article.name # Joku artikkeli
|
||||||
|
|
||||||
|
|
||||||
|
Translation hybrids can also be used as expressions.
|
||||||
|
::
|
||||||
|
|
||||||
|
session.query(Article).filter(Article.name['en'] == 'Some article')
|
||||||
|
|
||||||
|
.. _SQLAlchemy-i18n: https://github.com/kvesteri/sqlalchemy-i18n
|
Reference in New Issue
Block a user