Files @ 84b4fc9db016
Branch filter:

Location: kallithea/scripts/source_format.py

mads
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.
#!/usr/bin/env python3

# hg files 'set:!binary()&grep("^#!.*python")' 'set:**.py' | xargs scripts/source_format.py

import re
import sys


filenames = sys.argv[1:]

for fn in filenames:
    with open(fn) as f:
        org_content = f.read()

    mod_name = fn[:-3] if fn.endswith('.py') else fn
    mod_name = mod_name[:-9] if mod_name.endswith('/__init__') else mod_name
    mod_name = mod_name.replace('/', '.')
    def f(m):
        return '"""\n%s\n%s\n' % (mod_name, '~' * len(mod_name))
    new_content = re.sub(r'^"""\n(kallithea\..*\n)(~+\n)?', f, org_content, count=1, flags=re.MULTILINE)

    if new_content != org_content:
        with open(fn, 'w') as f:
            f.write(new_content)