##// END OF EJS Templates
i18n: make sure 'en' in Accept-Language is recognized as having 100% coverage...
i18n: make sure 'en' in Accept-Language is recognized as having 100% coverage The workaround in 7c7d6b5c07c7 no longer works after upstream addressed the main issue and released the changes in TurboGears 2.4.3 . Setting `i18n.native = en` in the .ini works as a workaround. The native language for translations is an implementation detail that users shouldn't have to configure, so we define it as a default value without making it explicit in the generated .ini template files. Note that even though TG will figure out that languages like `en_US` should fall back to using the `en` `kallithea.mo`, it doesn't consider `en_US` native if `en` is in the native list but `en_US` isn't. We thus include the most common aliases for `en` in the list.

File last commit:

r8638:278cc593 default
r8766:84b4fc9d stable
Show More
setup.cfg
48 lines | 836 B | text/x-ini | IniLexer
[egg_info]
tag_build =
tag_svn_revision = 0
tag_date = 0
[aliases]
test = pytest
[compile_catalog]
domain = kallithea
directory = kallithea/i18n
statistics = true
[extract_messages]
add_comments = TRANSLATORS:
output_file = kallithea/i18n/kallithea.pot
msgid-bugs-address = translations@kallithea-scm.org
copyright-holder = Various authors, licensing as GPLv3
[init_catalog]
domain = kallithea
input_file = kallithea/i18n/kallithea.pot
output_dir = kallithea/i18n
[update_catalog]
domain = kallithea
input_file = kallithea/i18n/kallithea.pot
output_dir = kallithea/i18n
previous = true
[build_sphinx]
source-dir = docs/
build-dir = docs/_build
all_files = 1
[upload_sphinx]
upload-dir = docs/_build/html
[pytype]
inputs =
kallithea
setup.py
exclude =
**/test_*.py
disable =
pyi-error
keep_going = True
#jobs = 3