Clean run results in modifications to en-us.py

[davidebbo]

Not sure if it's something I'm doing, but this has been bugging me for a while. If I run the web site from a clean repo, I instantly see en-us.py get modified, with many lines added. Among others, it adds:

'Jump to results': 'Jump to results',
'Linnean Society': 'Linnean Society',
'Occurrence': 'Occurrence',

Where are these coming from?

[lentinj]

Web2py's auto-i18n magic:

https://github.com/OneZoom/OZtree/blob/main/models/db.py#L44-L45

http://web2py.com/books/default/chapter/29/04/the-core#Translating-variables

We don't keep these derived files up-to-date though, I think we should be turning it off by default.

[hyanwong]

Yep. We should fix this. What happens is that web2py makes "automatic translations" into different languages whenever a client visits the site with that language set. Whenever we make a new "translatable string", such as T('a new string'), web2py then creates internationalised versions for later editing, by simply duplicating the text. Jamie thinks we should not allow this happen on the production site, but we could allow it on beta.

IMO, the easy fix is, once we have established a reasonable set of strings, to leave this to happen on beta.onezoom.org, then commit the changes into the main repo? But maybe @lentinj has a better idea.

[lentinj]

(@davidebbo, web2py has some management pages with a translation GUI, which people have used to translate onezoom via. beta.onezoom.org before, thus why Yan is suggesting allowing it on beta)

We could start a regime where we commit any changes to the languages files with every commit, but it'd make the commit log a lot more noisy (assuming I don't forget and then have to do follow up commits...). I'd prefer if we:

• Put T.is_writable behind it's own default-off config option, so these files don't churn on our laptops
• Turn this config option on for beta.onezoom.org
• Leave these files to churn on beta, assume through testing all strings will be gathered up
• Commit any language changes after someone has updated the corresponding native language strings from beta

This would be a bit annoying if you wanted to use the translation machinery locally, since you'd have to go gather strings yourself. But I don't think this has come up yet? And it's what would need to happen today anyway.

[hyanwong]

This sounds good to me.

Alternatively, we could only allow T.is_writable if is_testing is False? Then by default that will work on beta but be switched off on production. But it will still churn on @davidebbo 's machine, as is_testing = True is the default.

Another possibility is to set an appconfig.ini setting (allow_translation_string_writing)

[davidebbo]

Thanks for all the details. I confirm that is I set is_testing = False in db.py, it doesn't happen. Downside is that I now have db.py with changes instead of en-us.py :)

Anyway, this is not a huge deal at the moment, so we can just track it and deal with it once we're passed this new release.

[hyanwong]

Ah, I forgot that I had already implemented that, so that we don't write to the internationalised strings on production.

We could change it so that the default (on github) setting is is_testing=False, but I quite like having the default printing out errors etc to console if necessary.

[lentinj]

The default of is_testing = True is definitely useful, there's a lot more testing than production after all.

An allow_translation_string_writing that defaults to False means we can switch the two independently.

[davidebbo]

@lentinj Right, we should decouple them. Do you mean having allow_translation_string_writing as a config setting? I can add that, e.g. in the general section.

Side note, en-en in T.set_current_languages('en', 'en-en') was probably meant to be en-us? I don't think en-en is a thing...

[lentinj]

Yup, please do.

If you do, watch out for myconf.take(), if a config option doesn't exist, then it fires an exception, rather than returning a default.

We should move to having a helper function do the try/except, but I don't think that's happened yet.

[davidebbo]

We should move to having a helper function do the try/except, but I don't think that's happened yet.

There is already one: myconf.get(). However, that doesn't support passing a cast, which is unfortunate.

[davidebbo]

It does however do automatic casting of ints, and recognizes true/false, so it's quite usable. See https://github.com/web2py/web2py/blob/master/gluon/contrib/appconfig.py#L60-L79

[lentinj]

I'm sure there was something else myconf.get() was missing, maybe recursion through "section.thing"?

Could well be that this has since been fixed in web2py, and I've never updated my brain to match.

[davidebbo]

I'll play around with it and send a PR.

[hyanwong]

T.set_current_languages('en', 'en-en')

It's what they recommend in the web2py docs:

http://web2py.com/books/default/chapter/29/04/the-core#Determining-the-language

I guess it's a web2py shorthand, for plain en. I think it's fine to leave as-is.

[davidebbo]

I guess it's a web2py shorthand, for plain en. I think it's fine to leave as-is.

Yep, no reason to mess with it, even though it is unusual!