with all due respect for all the efforts people are putting in, I exploit this opportunity to raise my concerns for the I8 issues in kernel against “ignorant coding practice”
Take “get_print” and “attach_print methods” as an example and the recent currency objects disturbance which is still not corrected and not even cared for by the developer who messed it up in the first place.
Please make sure when you are coding, the software is getting highly international and there is at least the rest of the world outside your country. Make sure that the system level language settings, the interface settings of the user and the Frappe settings for any instance may differ and you code accordingly. You cannot let one method have a language override and let a similar function without this option. A system may run on an English setting having Turkish reports to be printed with the user having a German interface. The user should always have the ability to make transactions from any language and the outputs should be coming out as expected by the business rules.
Happy to discuss this with any developer.
No doubt ‘international’ users share in your interest and frustration, and fortunately with some care and effort the language translation issue can be overcome…
My thoughts FWIW -
The code is THE direct concrete document to inform those developers not sure how not to run afoul of internationalization best practice.
But since ERPNext is developed for native EN by default (I assume?), of course EN language developers can remain misinformed.
The good news, to me at least? Basic German DE translation test code can be found here!!
(The code is commented out, my guess since the tests are targeted to run and pass in a DE local environment?)
Additional basic test suites for Turkish TR, Spanish ES, French FR and so on could be implemented by those concerned communities based on the DE test ones here, no?
Another thought - the DE community may want to run (and record) a webinar on that topic, similar this that @Martin_Seibert and team kindly sponsor here Join our virtual documentation sprint - Help us improve the documentation and show use cases to the world!
For reference here are intro docs Docutils Internationalization
The language translation dictionaries can be found like so, for EN and FR:
frappe@ubuntu:~/frappe-bench$ find . -name '*en*.csv' ./apps/erpnext/erpnext/translations/en-US.csv ./apps/erpnext/erpnext/translations/en-GB.csv ./apps/erpnext/erpnext/translations/en.csv ./apps/frappe/frappe/translations/en-US.csv ./apps/frappe/frappe/translations/en-GB.csv ./apps/frappe/frappe/translations/en.csv frappe@ubuntu:~/frappe-bench$ find . -name '*fr*.csv' ./apps/erpnext/erpnext/translations/fr.csv ./apps/erpnext/erpnext/translations/fr-CA.csv ./apps/frappe/frappe/translations/fr.csv ./apps/frappe/frappe/translations/fr-CA.csv
I am afraid you don’t get me.
I am maintaining the TR code for num2words and I have no problems in writing, executing tests or translating software literals.
My concern is the recently diminishing coding quality especially in polluting the kernel with local applications and business logic. I guess that is a result of overenthusiastic developer efforts without proper business domain knowledge.
This may easily kill this project very fast!
Please share your code and submit this as a PR - that would be a big help to the ERPNext and Frappe internationalization effort!
Your fellow TR users will thank you. But also that would be an especially helpful learning guide for EN and non-EN developers alike.
I expect Frappe will require a test to illustrate and exercise your code. That adds to quality which is a good thing too
num2words repo has been updated with relevant tests for the repo. A version update in requirements need to be performed for the whole frappe and erpnext packages. I will post a PR on GitHub
Excellent news @Tufan_Kaynak2 - for the TR and DE language communities to take the lead here will point the way for all the others to follow suit.
Say test_TR_translation, test_DE_translation, test_FR_translation and so on…