Archives
Contributors
-
Re: Reviews
Hello,
Thanks for opening the discussion.
The board worked on a procedure introducing module maturity levels, and it involved lowering the barriers to merging.
Maintainer roles and ocabot ale tried to improve this.
Having active maintainers is really important for things to work, so I personally appreciate your suggestions.
Food for though, I recently found this an interesting read, and I wonder how close we could get of it.
https://martinfowler.com/articles/ship-show-ask.html
Thanks
Daniel
On 16/09/21 12:51, Tom Blauwendraat wrote:
Hi all, For years, OCA has a big problem with unmerged PR's. Also, even if there are 2 reviews then PSC's generally don't respond to merge requests. The answer has always been "let's review more" or "Let's use gitaggregator and so we can use unmerged PR's". But why don't we try something more radical: - Let's write a script to assign "maintainer" role for all modules to the person who committed the oldest/original version of it - If maintainer does not respond to a ping longer than 1 month he loses the maintainer role, which then changes to the default maintainer that is set for the full repo. - Let's require only 1 positive review from now on. After that the maintainer can merge. --> I don't think that having 2 reviewers is always necessary and it also does not prevent bugs from being merged - this happens anyway. I used to have high trust of merged OCA modules but after seeing some quite ugly bugs and incomplete work being merged I am starting to think that maybe the quality of the unmerged stuff is not that bad as compared to what is actually merged. The maintainer can prevent really bad changes from entering, by just closing the PR. Tom
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Daniel Reis - 02:06 - 16 Sep 2021 -
SIGNATURE WIDGET ODOO 13
Hello Community,
I wanted to use signature widget in odoo 13, but i can't remove horizontal line, and there are no customizing to change string parameter 'Signature'. can you help me please.
Best regards.
by akalala - 01:55 - 16 Sep 2021 -
Request for Reviews
Hello Contributors, Greeting! On behalf of Initos team member for OCA contributions I am writing this email. Currently we focus on migration of module to v14 as well as doing some reviews. I would like to request you that please let us know if there are any reviews we can do for you. You can assign to @fshah-initos / dsolanki-initos / hkapatel-initos Thank You! Regards, Dhara Solanki
by Dhara Solanki - 02:21 - 15 Sep 2021 -
Odoo Developers Telegram Group
Welcome to worlds largest Odoo Developers Group on TelegramJoin Odoo Developers Telegram Group https://t.me/odoo_developers--
Or
Search " Odoo Developers" in your Telegram.
Regards,
Albin John
by Albin John - 11:46 - 15 Sep 2021 -
Re: Translations and UI
Thanks Moises,
I have proposed PR here : https://github.com/OCA/server-backend/pull/132
Best Regards,
Rémi CAZENAVE
------
SCOP LE FILAMENT
06.87.23.26.04
remi@le-filament.comLe 08/09/2021 à 16:17, Moises Lopez a écrit :
Hi Rémi,
If you like contribute it in OCA umbrella you can do it in
Ping me in order to review it, please@moylop260
--
On Wed 8 Sep 2021 at 4:32 a.m. Rémi CAZENAVE - Le Filament <remi@le-filament.com> wrote:
Thank you Yann, Joerg and Tom for your proposals.
I have implemented a new module based on the proposal from Yann : https://sources.le-filament.com/lefilament/base_default_lang_translate
I added a boolean on res_lang in order to select your default language. Any update performed with this language would then :
- Update translation in this language (default behaviour)
- Update source terms for all translations with the new value
- Store new value in object table in database
I also have added a function to modify state of existing translations in case a source term is modified (state changes to to_translate).
Still need to work on scripts to bring database back to a proper state, cleaning all the mess coming from default Odoo behavior :)
Of course if you believe this could be useful for OCA, I can create a PR to move it under OCA umbrella.
Best Regards,
Rémi CAZENAVE
------
SCOP LE FILAMENT
06.87.23.26.04
remi@le-filament.comLe 07/09/2021 à 13:31, Yann Papouin a écrit :
This is an old PR from launchpad that I still use in production on odoo 12.0
With this patch, the current language is considered the database one (written to tables) and always override 'en_US', but it could be easily modified to only override when the current env.context lang is 'fr*', that way the source (database language) becomes "french".
It is better to have this patch running since the first launch but a simple script could be written to override "database" data with the french one.
--
Yann PAPOUIN, Ingénieur R&D | DEC
Le mar. 7 sept. 2021 à 10:22, Rémi CAZENAVE - Le Filament <remi@le-filament.com> a écrit :
Dear all,
We are struggling with dealing with translations for one of our customers using mainly advanced surveys (with Odoo 12.0).
Basically, they design all their surveys in French + they use template surveys that they duplicate for new ones, changing titles and a few labels / questions inside.
Then they need to translate these surveys in English and German, since some of them are sent to non-French speaking companies.
Because Odoo considers that sources terms are en_US, we have everywhere names in source terms like "template (copy)", which is of course not the term they need to translate in English and German but the French terms are to be translated in these languages. Also names in survey tables are the original en_US ones (with (copy) inside) which means nothing to them...
I am not sure how to address this ? I have seen a number of issues on GitHub which are marked as normal behaviour and won't fix, but of course this does not help.
I have tried a few things, and my last idea is the following : force context to lang = en_US and do not translate in French (leave terms untranslated) so that it will use source terms for French. Then activate en_GB and de_DE for translating french source in these languages.
I have tried using context="{'lang': 'en_US'}" on translated fields in views but this does not seem to be taken into account, only context in action is but this use all fields in English then (meaning labels, group strings, etc.), which is not the intended purpose.
We will probably override write() actions to force lang in context.
I suppose many of you have already faced issues with translations, any idea, remark, link is welcome !
Best Regards,
--
Rémi CAZENAVE
------
SCOP LE FILAMENT_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
Moisés López CalderónMobile: (+521) 477-752-22-30Twitter: @moylop260Twitter: @vauxoo_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Rémi Cazenave - 01:56 - 13 Sep 2021 -
Re: V14, python version
Then I think you can press with that on the issue.Regards.
by Pedro M. Baeza - 05:41 - 8 Sep 2021 -
Re: V14, python version
Last Debian stable is Bullseye/11 has Python 3.9A good news then ?Le mer. 8 sept. 2021 à 16:17, Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com> a écrit :Well, I mean on the moment of the release. Later patches for upper version compatibility depends on the official supported versions and the will of Odoo stuff.Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by David BEAL - 05:36 - 8 Sep 2021 -
Re: V14, python version
Well, I mean on the moment of the release. Later patches for upper version compatibility depends on the official supported versions and the will of Odoo stuff.Regards.
by Pedro M. Baeza - 04:16 - 8 Sep 2021 -
Re: Translations and UI
Hi Rémi,If you like contribute it in OCA umbrella you can do it inPing me in order to review it, please@moylop260--On Wed 8 Sep 2021 at 4:32 a.m. Rémi CAZENAVE - Le Filament <remi@le-filament.com> wrote:Thank you Yann, Joerg and Tom for your proposals.
I have implemented a new module based on the proposal from Yann : https://sources.le-filament.com/lefilament/base_default_lang_translate
I added a boolean on res_lang in order to select your default language. Any update performed with this language would then :
- Update translation in this language (default behaviour)
- Update source terms for all translations with the new value
- Store new value in object table in database
I also have added a function to modify state of existing translations in case a source term is modified (state changes to to_translate).
Still need to work on scripts to bring database back to a proper state, cleaning all the mess coming from default Odoo behavior :)
Of course if you believe this could be useful for OCA, I can create a PR to move it under OCA umbrella.
Best Regards,
Rémi CAZENAVE
------
SCOP LE FILAMENT
06.87.23.26.04
remi@le-filament.comLe 07/09/2021 à 13:31, Yann Papouin a écrit :
This is an old PR from launchpad that I still use in production on odoo 12.0
With this patch, the current language is considered the database one (written to tables) and always override 'en_US', but it could be easily modified to only override when the current env.context lang is 'fr*', that way the source (database language) becomes "french".
It is better to have this patch running since the first launch but a simple script could be written to override "database" data with the french one.
--
Yann PAPOUIN, Ingénieur R&D | DEC
Le mar. 7 sept. 2021 à 10:22, Rémi CAZENAVE - Le Filament <remi@le-filament.com> a écrit :
Dear all,
We are struggling with dealing with translations for one of our customers using mainly advanced surveys (with Odoo 12.0).
Basically, they design all their surveys in French + they use template surveys that they duplicate for new ones, changing titles and a few labels / questions inside.
Then they need to translate these surveys in English and German, since some of them are sent to non-French speaking companies.
Because Odoo considers that sources terms are en_US, we have everywhere names in source terms like "template (copy)", which is of course not the term they need to translate in English and German but the French terms are to be translated in these languages. Also names in survey tables are the original en_US ones (with (copy) inside) which means nothing to them...
I am not sure how to address this ? I have seen a number of issues on GitHub which are marked as normal behaviour and won't fix, but of course this does not help.
I have tried a few things, and my last idea is the following : force context to lang = en_US and do not translate in French (leave terms untranslated) so that it will use source terms for French. Then activate en_GB and de_DE for translating french source in these languages.
I have tried using context="{'lang': 'en_US'}" on translated fields in views but this does not seem to be taken into account, only context in action is but this use all fields in English then (meaning labels, group strings, etc.), which is not the intended purpose.
We will probably override write() actions to force lang in context.
I suppose many of you have already faced issues with translations, any idea, remark, link is welcome !
Best Regards,
--
Rémi CAZENAVE
------
SCOP LE FILAMENT_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
Moisés López CalderónMobile: (+521) 477-752-22-30Twitter: @moylop260Twitter: @vauxoo
by Moisés López Calderón - 04:15 - 8 Sep 2021 -
Re: V14, python version
> It's current Debian stable python version. I offer the python version of Debian stable at the time of the release of the Odoo version in question, cf https://github.com/odoo/odoo/pull/71437#issuecomment-853865869 -- Your partner for the hard Odoo problems https://hunki-enterprises.com
by Holger Brunn - 04:05 - 8 Sep 2021 -
Re: V14, python version
It's current Debian stable python version.Regards.El mié., 8 sept. 2021 15:12, Tom Blauwendraat <tom@sunflowerweb.nl> escribió:
I think I read in another discussion that their philosophy was to support the Python version of the oldest, still supported Ubuntu LTS version. But I could be wrong.
On 9/8/21 3:02 PM, David Beal wrote:
Hi all,
What's your opinion here ?
Le mar. 8 déc. 2020 à 14:16, Raphaël Valyi <rvalyi@akretion.com> a écrit :
right on the spot David.
Now sadly I don't think we can expect any move from Odoo SA on this. IMHO they support old Python versions a bit by accident, because they come from legacy Python so by default they tend to have legacy Python compliant code while they make efforts to embrace new Python versions.
Even if it's not just by accident, Odoo SA follows a different logic: they maintain only 350 modules or so, they push new customers to new versions and push their paid migration. The ERP reality is not migrating every year nor even every 2 years on large projects. Take the LTS resonance (every 2 years so far) into account, and consider a company has any problem to migrate after 2 years only and now they probably wait 4 years and Odoo SA policy forces them to run unmaintained code with ERP features exposed on the web by packages exposed to security issues... Instead Odoo SA likes his ERP to be just one click away to install and test on any distro, even if (and may be especially if) it's not to run it for real and buy some comercial Odoo hosting with them or a partner later.
So I agree with you about how bad this is to support nearly end of life Python versions in the newest Odoo release where choice is available, but I think this is up to the OCA to educate the community, explain it that choosing libs done for nearly end of life Python is what will make their whole ERP obsolete with security exploits all exposed over the web in just 1 or 2 years. So I think the OCA should assume a different and more responsible policy than Odoo SA and require recent enough Python on recent Odoo versions (like what about 3.7 on v14, I mean at least a Python version with a life cycle compatible with the Odoo official one).
Regards.
On Tue, Dec 8, 2020 at 9:16 AM David Beal <david.beal@akretion.com> wrote:
Hi,
FYI another example of maintenance burden of multiple python versions
For the future, we probably need to be more persuasive to convince Odoo to only support recentest versions
It will impact OCA and your container projects.
Regards
David BEAL - akretion.comConsultant
Odoo Intégration / Développement
Le lun. 19 oct. 2020 à 17:16, Juan José Scarafía (ADHOC) <scarafia.juanjose@gmail.com> a écrit :
Thanks Moi!IMHO, we should go for python 3.8 on v14Stay as we are on any previous version.
On Mon, Oct 19, 2020 at 12:06 PM Moises Lopez <moylop260@vauxoo.com> wrote:
> David, An example of ugly code to support python 3.7 or lower is here
So, this code must be applied for 3.6 too (I thought only 3.7)
> Stéphane, With that we can safely announce that OCA supports and tests 14.0 with py 3.6 and 3.8, and that 3.7 should work but we don't test it due to limited resources.
Then this sentence change a little bit.Since that the ugly code is required for 3.6 too.
Fabien Meghazi from Odoo commented the following:
They are preparing to migrate Odoo v13.0 servers to py3.8 in OdooSH
So, py3.8 will be more stable than before.
I think it is because py3.6 will be obsolete in 1 year (2021-12)In 1 year will be obsolete Odoo v12.0, so it won't require migrate to py3.8And the latest stable version of python in Ubuntu LTS is 3.8 (3.7 was bypassed)
Should we work with patches to support python versions that will be obsolete in the short term or won't be used?
Even if we can enable 2 or more python versions in the CI, it will require extra code.
IMHO even if Odoo in this moment is supporting py3.6,in the short term it is a waste of time and resources.But I don't know I could be wrong.
What do you think after this?
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Raphaël ValyiFounder and consultant
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Pedro M. Baeza - 03:16 - 8 Sep 2021 -
Re: V14, python version
I think I read in another discussion that their philosophy was to support the Python version of the oldest, still supported Ubuntu LTS version. But I could be wrong.
On 9/8/21 3:02 PM, David Beal wrote:
Hi all,
What's your opinion here ?
Le mar. 8 déc. 2020 à 14:16, Raphaël Valyi <rvalyi@akretion.com> a écrit :
right on the spot David.
Now sadly I don't think we can expect any move from Odoo SA on this. IMHO they support old Python versions a bit by accident, because they come from legacy Python so by default they tend to have legacy Python compliant code while they make efforts to embrace new Python versions.
Even if it's not just by accident, Odoo SA follows a different logic: they maintain only 350 modules or so, they push new customers to new versions and push their paid migration. The ERP reality is not migrating every year nor even every 2 years on large projects. Take the LTS resonance (every 2 years so far) into account, and consider a company has any problem to migrate after 2 years only and now they probably wait 4 years and Odoo SA policy forces them to run unmaintained code with ERP features exposed on the web by packages exposed to security issues... Instead Odoo SA likes his ERP to be just one click away to install and test on any distro, even if (and may be especially if) it's not to run it for real and buy some comercial Odoo hosting with them or a partner later.
So I agree with you about how bad this is to support nearly end of life Python versions in the newest Odoo release where choice is available, but I think this is up to the OCA to educate the community, explain it that choosing libs done for nearly end of life Python is what will make their whole ERP obsolete with security exploits all exposed over the web in just 1 or 2 years. So I think the OCA should assume a different and more responsible policy than Odoo SA and require recent enough Python on recent Odoo versions (like what about 3.7 on v14, I mean at least a Python version with a life cycle compatible with the Odoo official one).
Regards.
On Tue, Dec 8, 2020 at 9:16 AM David Beal <david.beal@akretion.com> wrote:
Hi,
FYI another example of maintenance burden of multiple python versions
For the future, we probably need to be more persuasive to convince Odoo to only support recentest versions
It will impact OCA and your container projects.
Regards
David BEAL - akretion.comConsultant
Odoo Intégration / Développement
Le lun. 19 oct. 2020 à 17:16, Juan José Scarafía (ADHOC) <scarafia.juanjose@gmail.com> a écrit :
Thanks Moi!IMHO, we should go for python 3.8 on v14Stay as we are on any previous version.
On Mon, Oct 19, 2020 at 12:06 PM Moises Lopez <moylop260@vauxoo.com> wrote:
> David, An example of ugly code to support python 3.7 or lower is here
So, this code must be applied for 3.6 too (I thought only 3.7)
> Stéphane, With that we can safely announce that OCA supports and tests 14.0 with py 3.6 and 3.8, and that 3.7 should work but we don't test it due to limited resources.
Then this sentence change a little bit.Since that the ugly code is required for 3.6 too.
Fabien Meghazi from Odoo commented the following:
They are preparing to migrate Odoo v13.0 servers to py3.8 in OdooSH
So, py3.8 will be more stable than before.
I think it is because py3.6 will be obsolete in 1 year (2021-12)In 1 year will be obsolete Odoo v12.0, so it won't require migrate to py3.8And the latest stable version of python in Ubuntu LTS is 3.8 (3.7 was bypassed)
Should we work with patches to support python versions that will be obsolete in the short term or won't be used?
Even if we can enable 2 or more python versions in the CI, it will require extra code.
IMHO even if Odoo in this moment is supporting py3.6,in the short term it is a waste of time and resources.But I don't know I could be wrong.
What do you think after this?
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Raphaël ValyiFounder and consultant
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Tom Blauwendraat - 03:11 - 8 Sep 2021 -
Re: V14, python version
Hi all,What's your opinion here ?Le mar. 8 déc. 2020 à 14:16, Raphaël Valyi <rvalyi@akretion.com> a écrit :right on the spot David.Now sadly I don't think we can expect any move from Odoo SA on this. IMHO they support old Python versions a bit by accident, because they come from legacy Python so by default they tend to have legacy Python compliant code while they make efforts to embrace new Python versions.Even if it's not just by accident, Odoo SA follows a different logic: they maintain only 350 modules or so, they push new customers to new versions and push their paid migration. The ERP reality is not migrating every year nor even every 2 years on large projects. Take the LTS resonance (every 2 years so far) into account, and consider a company has any problem to migrate after 2 years only and now they probably wait 4 years and Odoo SA policy forces them to run unmaintained code with ERP features exposed on the web by packages exposed to security issues... Instead Odoo SA likes his ERP to be just one click away to install and test on any distro, even if (and may be especially if) it's not to run it for real and buy some comercial Odoo hosting with them or a partner later.So I agree with you about how bad this is to support nearly end of life Python versions in the newest Odoo release where choice is available, but I think this is up to the OCA to educate the community, explain it that choosing libs done for nearly end of life Python is what will make their whole ERP obsolete with security exploits all exposed over the web in just 1 or 2 years. So I think the OCA should assume a different and more responsible policy than Odoo SA and require recent enough Python on recent Odoo versions (like what about 3.7 on v14, I mean at least a Python version with a life cycle compatible with the Odoo official one).Regards.On Tue, Dec 8, 2020 at 9:16 AM David Beal <david.beal@akretion.com> wrote:Hi,FYI another example of maintenance burden of multiple python versionsFor the future, we probably need to be more persuasive to convince Odoo to only support recentest versionsIt will impact OCA and your container projects.Regards
David BEAL - akretion.comConsultantOdoo Intégration / DéveloppementLe lun. 19 oct. 2020 à 17:16, Juan José Scarafía (ADHOC) <scarafia.juanjose@gmail.com> a écrit :Thanks Moi!IMHO, we should go for python 3.8 on v14Stay as we are on any previous version.On Mon, Oct 19, 2020 at 12:06 PM Moises Lopez <moylop260@vauxoo.com> wrote:> David, An example of ugly code to support python 3.7 or lower is hereSo, this code must be applied for 3.6 too (I thought only 3.7)> Stéphane, With that we can safely announce that OCA supports and tests 14.0 with py 3.6 and 3.8, and that 3.7 should work but we don't test it due to limited resources.Then this sentence change a little bit.Since that the ugly code is required for 3.6 too.Fabien Meghazi from Odoo commented the following:They are preparing to migrate Odoo v13.0 servers to py3.8 in OdooSHSo, py3.8 will be more stable than before.I think it is because py3.6 will be obsolete in 1 year (2021-12)In 1 year will be obsolete Odoo v12.0, so it won't require migrate to py3.8And the latest stable version of python in Ubuntu LTS is 3.8 (3.7 was bypassed)Should we work with patches to support python versions that will be obsolete in the short term or won't be used?Even if we can enable 2 or more python versions in the CI, it will require extra code.IMHO even if Odoo in this moment is supporting py3.6,in the short term it is a waste of time and resources.But I don't know I could be wrong.What do you think after this?_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Raphaël ValyiFounder and consultant_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by David BEAL - 03:01 - 8 Sep 2021 -
Re: Translations and UI
Thank you Yann, Joerg and Tom for your proposals.
I have implemented a new module based on the proposal from Yann : https://sources.le-filament.com/lefilament/base_default_lang_translate
I added a boolean on res_lang in order to select your default language. Any update performed with this language would then :
- Update translation in this language (default behaviour)
- Update source terms for all translations with the new value
- Store new value in object table in database
I also have added a function to modify state of existing translations in case a source term is modified (state changes to to_translate).
Still need to work on scripts to bring database back to a proper state, cleaning all the mess coming from default Odoo behavior :)
Of course if you believe this could be useful for OCA, I can create a PR to move it under OCA umbrella.
Best Regards,
Rémi CAZENAVE
------
SCOP LE FILAMENT
06.87.23.26.04
remi@le-filament.comLe 07/09/2021 à 13:31, Yann Papouin a écrit :
This is an old PR from launchpad that I still use in production on odoo 12.0
With this patch, the current language is considered the database one (written to tables) and always override 'en_US', but it could be easily modified to only override when the current env.context lang is 'fr*', that way the source (database language) becomes "french".
It is better to have this patch running since the first launch but a simple script could be written to override "database" data with the french one.
--
Yann PAPOUIN, Ingénieur R&D | DEC
Le mar. 7 sept. 2021 à 10:22, Rémi CAZENAVE - Le Filament <remi@le-filament.com> a écrit :
Dear all,
We are struggling with dealing with translations for one of our customers using mainly advanced surveys (with Odoo 12.0).
Basically, they design all their surveys in French + they use template surveys that they duplicate for new ones, changing titles and a few labels / questions inside.
Then they need to translate these surveys in English and German, since some of them are sent to non-French speaking companies.
Because Odoo considers that sources terms are en_US, we have everywhere names in source terms like "template (copy)", which is of course not the term they need to translate in English and German but the French terms are to be translated in these languages. Also names in survey tables are the original en_US ones (with (copy) inside) which means nothing to them...
I am not sure how to address this ? I have seen a number of issues on GitHub which are marked as normal behaviour and won't fix, but of course this does not help.
I have tried a few things, and my last idea is the following : force context to lang = en_US and do not translate in French (leave terms untranslated) so that it will use source terms for French. Then activate en_GB and de_DE for translating french source in these languages.
I have tried using context="{'lang': 'en_US'}" on translated fields in views but this does not seem to be taken into account, only context in action is but this use all fields in English then (meaning labels, group strings, etc.), which is not the intended purpose.
We will probably override write() actions to force lang in context.
I suppose many of you have already faced issues with translations, any idea, remark, link is welcome !
Best Regards,
--
Rémi CAZENAVE
------
SCOP LE FILAMENT_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Rémi Cazenave - 11:31 - 8 Sep 2021 -
Re: A methodology / best practice / Odoo / Python question
Simone! Thanx a lot! That's exactly what I was looking for. Seems so straightforward now. Best regards Radovan On utorok 7. septembra 2021 10:32:07 CEST Simone Rubino wrote: > Hi, you can also use functions to render QWeb templates, so you can declare > the function in any Python file and add it to the values used to render the > pages that will need your function. For instance, see how `format_date` is > used in > https://github.com/odoo/odoo/blob/070bec2f3a7a50c6fc8f104cf92a9416ebc001b8/ > addons/mail/models/mail_render_mixin.py#L244 [1] for rendering e-mails. To > add your function to the values of any website page you can override > `_prepare_qcontext` ( > https://github.com/odoo/odoo/blob/3f96cff0aa5097a386c289cf9fd2aeb3048376ab/ > odoo/addons/base/models/ir_ui_view.py#L1720 [2] ) or you can add it > individually to the values of the page that need your function. On Mon, 6 > Sept 2021 at 10:26, Radovan Skolnik < radovan@skolnik.info [3] > wrote: > Hello, > > I am struggling with this for a while so I have decided to ask here. I am > building a module that would be showing active filters/ordering as tags on > e-commerce by parsing query part of the URL. Besides the standard ones > (search, order) we are also using brands filter and also custom_info. Both > of these can have multiple options checked. User has the option to remove > them individually instead of searching for appropriate checkobxes on the > page. Now my approach is basically iterate through key/value pairs and for > each generate what looks like a tag visually with URL that has that > key/value pair removed (so it in fact removes that part of filter). For > that I have devised a code like this: > > from odoo.http import request > > from werkzeug import OrderedMultiDict > from werkzeug.urls import url_parse, url_encode > > def _get_filtered_url(param, value): > filtered_args = OrderedMultiDict(filter(lambda arg: arg[0]!=param or > arg[1]!=value, request.httprequest.args.items(multi=True))) url = > url_parse(request.httprequest.url) > return url.replace(query=url_encode(filtered_args)).to_url() > > Now this code is obviously not a object/class method - it should be (in my > opinion) a static method. Now the question is: static method of what? > Because I need to be able to call it from XML template that renders part of > WebsiteSale. I guess I could create a dummy (transient?) class and call it > like request.env['my_transient_class']._get_filtered_url(param, value) but > that somehow does not seem right to me. Or is it the right way? I am trying > to write a clean concise code that is not hacky. > > Any advice is welcome here. Thank you very much. > > Best regards > > Radovan Skolnik > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 [4] > Post to: mailto: contributors@odoo-community.org [5] > Unsubscribe: https://odoo-community.org/groups?unsubscribe [6] > > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 [7] > Post to: mailto:contributors@odoo-community.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe [8] > > > > [1] > https://github.com/odoo/odoo/blob/070bec2f3a7a50c6fc8f104cf92a9416ebc001b8/ > addons/mail/models/mail_render_mixin.py#L244 [2] > https://github.com/odoo/odoo/blob/3f96cff0aa5097a386c289cf9fd2aeb3048376ab/ > odoo/addons/base/models/ir_ui_view.py#L1720 [3] mailto:radovan@skolnik.info > [4] https://odoo-community.org/groups/contributors-15 > [5] mailto:contributors@odoo-community.org > [6] https://odoo-community.org/groups?unsubscribe > [7] https://odoo-community.org/groups/contributors-15 > [8] https://odoo-community.org/groups?unsubscribe
by Radovan Skolnik - 01:40 - 7 Sep 2021 -
Re: Translations and UI
This is an old PR from launchpad that I still use in production on odoo 12.0With this patch, the current language is considered the database one (written to tables) and always override 'en_US', but it could be easily modified to only override when the current env.context lang is 'fr*', that way the source (database language) becomes "french".It is better to have this patch running since the first launch but a simple script could be written to override "database" data with the french one.--
Yann PAPOUIN, Ingénieur R&D | DECLe mar. 7 sept. 2021 à 10:22, Rémi CAZENAVE - Le Filament <remi@le-filament.com> a écrit :Dear all,
We are struggling with dealing with translations for one of our customers using mainly advanced surveys (with Odoo 12.0).
Basically, they design all their surveys in French + they use template surveys that they duplicate for new ones, changing titles and a few labels / questions inside.
Then they need to translate these surveys in English and German, since some of them are sent to non-French speaking companies.
Because Odoo considers that sources terms are en_US, we have everywhere names in source terms like "template (copy)", which is of course not the term they need to translate in English and German but the French terms are to be translated in these languages. Also names in survey tables are the original en_US ones (with (copy) inside) which means nothing to them...
I am not sure how to address this ? I have seen a number of issues on GitHub which are marked as normal behaviour and won't fix, but of course this does not help.
I have tried a few things, and my last idea is the following : force context to lang = en_US and do not translate in French (leave terms untranslated) so that it will use source terms for French. Then activate en_GB and de_DE for translating french source in these languages.
I have tried using context="{'lang': 'en_US'}" on translated fields in views but this does not seem to be taken into account, only context in action is but this use all fields in English then (meaning labels, group strings, etc.), which is not the intended purpose.
We will probably override write() actions to force lang in context.
I suppose many of you have already faced issues with translations, any idea, remark, link is welcome !
Best Regards,
--
Rémi CAZENAVE
------
SCOP LE FILAMENT_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Yann Papouin - 01:30 - 7 Sep 2021 -
Re: Translations and UI
My idea:
1. Write a one-time script that will replace all current source values for translated fields for records that are noupdate=1 or dont come from the database at all, with the French translation (gets rid of all the "copy names" and replace by something meaningful)
2. Add "en_GB" for English and dont use "en_US"
3. For any translated fields in future dont allow direct edit but force the user to use OCA "web_translate_dialog", which shows the source and all the translations in view so people will have to fill something meaningful always. We have made a module for this 'web_widget_enforce_translate', can opensource it when useful (wanted to, but didnt get the time to polish it)
On 9/7/21 10:22 AM, Rémi CAZENAVE - Le Filament wrote:
Dear all,
We are struggling with dealing with translations for one of our customers using mainly advanced surveys (with Odoo 12.0).
Basically, they design all their surveys in French + they use template surveys that they duplicate for new ones, changing titles and a few labels / questions inside.
Then they need to translate these surveys in English and German, since some of them are sent to non-French speaking companies.
Because Odoo considers that sources terms are en_US, we have everywhere names in source terms like "template (copy)", which is of course not the term they need to translate in English and German but the French terms are to be translated in these languages. Also names in survey tables are the original en_US ones (with (copy) inside) which means nothing to them...
I am not sure how to address this ? I have seen a number of issues on GitHub which are marked as normal behaviour and won't fix, but of course this does not help.
I have tried a few things, and my last idea is the following : force context to lang = en_US and do not translate in French (leave terms untranslated) so that it will use source terms for French. Then activate en_GB and de_DE for translating french source in these languages.
I have tried using context="{'lang': 'en_US'}" on translated fields in views but this does not seem to be taken into account, only context in action is but this use all fields in English then (meaning labels, group strings, etc.), which is not the intended purpose.
We will probably override write() actions to force lang in context.
I suppose many of you have already faced issues with translations, any idea, remark, link is welcome !
Best Regards,
--
Rémi CAZENAVE
------
SCOP LE FILAMENT_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Tom Blauwendraat - 12:51 - 7 Sep 2021