Enlarge Language Code

[Bachstelze]

Could we enlarge the max_length value from current 15 to 36, so you can store easily python UUIDs in there?
With the current value you have to do more logic to avoid Errors from ('language_code', 'master') unicity vialation.

[spectras]

Hello,
Thanks for reporting here. I am not sure I understand the need. Could you detail the issue you're having with language_code and how increasing its max_length would solve it?

[Bachstelze]

I'm storing different translation suggestion for one language by simple use different language_codes for each. Creating a unique language_code is also quit simple by adding an incremental counter. But the problem is to use it in parallel functions, because you have to lock this small logic part for each creation which causes a big overhead. My proposal would be to enlarge the max_length so that you can store a unique code without any logic that have to be looked. The max size would be 36 characters if we want to support python core uuid (https://pymotw.com/3/uuid/index.html 36 would be the length of the hex value) or 22 if we want to support a library like https://github.com/skorokithakis/shortuuid

[spectras]

It seems you are digging into hvad's internals in a very unexpected way. I don't really want to encourage this as it breaks the fundamental paradigm of hvad, that translations are for displaying only and do not take active part in the data model or business logic.

In your example, you attach translation suggestions to an object. It is not the same concept as an hvad translation. I understand they are really close and it feels intuitive to try and implement them by re-using hvad translations. Yet hvad would work the other way around: attach translations to suggestions.

I would suggest you split it into:

• the actual instance translations, managed by hvad, one per language.
• a separate model for suggestions (that you could use to help the user fill the actual translations)

Suggestions are part of your business logic, and pushing that into hvad's own data model risks creating incompatibilities with future versions.

I guess if you insist on doing this anyway, I could make it possible to override the language_code field definition. You could then add your own language_code definition in TranslatedFields and set it as you like, as long as you are aware of the caveats of messing with a third party module's internals.

[Bachstelze]

Thanks for your advice.
I will probably rewrite my models and hopefully don't need my suggestion. Nevertheless, i think the possibility of overwrite the language_code field will help in other usages like generic language models and won't cost much dataspace.

[spectras]

Next hvad release will allow overriding language_code. I also took the opportunity of detecting other reserved name collisions instead of silently discarding them, it will avoid some headaches.