|
Description
Bernardo Gonzalez Kriegel
2019-12-18 12:37:00 UTC
Created attachment 96538 [details] [review] Bug 24262: Translate installer data in YAML format This patch adds the ability to: 1) Create new translation files from yaml installer files 2) Create installer directory for a given language It will not create a installer directory if it already exists. New (possible) translation files: xx-YY-installer.po xx-YY-installer-MARC21.po xx-YY-installer-UNIMARC.po Needs Bug 13897 (for yaml files) and Bug 18688 (for warnings) To test: 1) Apply patches from Bug 13897 and Bug 18688. 2) Apply this patch 3) Go to misc/translation 4) Create new translation files for a language $ ./translate create xx-YY check new file 'xx-YY-installer.po' 5) Copy ../../installer/data/mysql/en/optional/auth_val.yml into ../../installer/data/mysql/en/marcflavour/marc21/mandatory/ and ../../installer/data/mysql/en/marcflavour/unimarc/mandatory/ remove po/xx-YY*, then repeat creation check new files 'xx-YY-installer.po', 'xx-YY-installer-MARC21.po' and 'xx-YY-installer-UNIMARC.po' remove all new files 6) Create for xx-YY again and try update $ ./translate create xx-YY edit ../../installer/data/mysql/en/optional/auth_val.yml and change one char in one of the translatable values, also edit 'xx-YY-installer.po', translate the same string (in msgstr). Do an update $ ./translate update xx-YY check in 'xx-YY-installer.po' a fuzzy value for the translated value and the preservation of the translation Fix the translation, or add a new one. 7) Create an install dir for xx-YY ./translate install xx-YY Check new dir '../../installer/data/mysql/xx-YY/' Check files on it $ tree ../../installer/data/mysql/xx-YY/ and compare with ../../installer/data/mysql/en/ All installation files must be present 8) Try a new Koha install using this language in the usual way. Check in authorised_values for the translated string. 9) Try create an install dir for an existing language (eg. es-ES, de-DE or fr-FR ) Install dir is ignored and not changed. Created attachment 96540 [details] [review] Bug 24262: Translate installer data in YAML format This patch adds the ability to: 1) Create new translation files from yaml installer files 2) Create installer directory for a given language It will not create a installer directory if it already exists. New (possible) translation files: xx-YY-installer.po xx-YY-installer-MARC21.po xx-YY-installer-UNIMARC.po Needs Bug 13897 (for yaml files) and Bug 18688 (for warnings) To test: 1) Apply patches from Bug 13897 and Bug 18688. 2) Apply this patch 3) Go to misc/translation 4) Create new translation files for a language $ ./translate create xx-YY check new file 'xx-YY-installer.po' 5) Copy ../../installer/data/mysql/en/optional/auth_val.yml into ../../installer/data/mysql/en/marcflavour/marc21/mandatory/ and ../../installer/data/mysql/en/marcflavour/unimarc/mandatory/ remove po/xx-YY*, then repeat creation check new files 'xx-YY-installer.po', 'xx-YY-installer-MARC21.po' and 'xx-YY-installer-UNIMARC.po' remove all new files 6) Create for xx-YY again and try update $ ./translate create xx-YY edit ../../installer/data/mysql/en/optional/auth_val.yml and change one char in one of the translatable values, also edit 'xx-YY-installer.po', translate the same string (in msgstr). Do an update $ ./translate update xx-YY check in 'xx-YY-installer.po' a fuzzy value for the translated value and the preservation of the translation Fix the translation, or add a new one. 7) Create an install dir for xx-YY ./translate install xx-YY Check new dir '../../installer/data/mysql/xx-YY/' Check files on it $ tree ../../installer/data/mysql/xx-YY/ and compare with ../../installer/data/mysql/en/ All installation files must be present 8) Try a new Koha install using this language in the usual way. Check in authorised_values for the translated string. 9) Try create an install dir for an existing language (eg. es-ES, de-DE or fr-FR ) Install dir is ignored and not changed. Created attachment 96593 [details] [review] Bug 24262: Translate installer data in YAML format This patch adds the ability to: 1) Create new translation files from yaml installer files 2) Create installer directory for a given language It will not create a installer directory if it already exists. New (possible) translation files: xx-YY-installer.po xx-YY-installer-MARC21.po xx-YY-installer-UNIMARC.po Needs Bug 13897 (for yaml files) and Bug 18688 (for warnings) To test: 1) Apply patches from Bug 13897 and Bug 18688. 2) Apply this patch 3) Go to misc/translation 4) Create new translation files for a language $ ./translate create xx-YY check new file 'xx-YY-installer.po' 5) Copy ../../installer/data/mysql/en/optional/auth_val.yml into ../../installer/data/mysql/en/marcflavour/marc21/mandatory/ and ../../installer/data/mysql/en/marcflavour/unimarc/mandatory/ remove po/xx-YY*, then repeat creation check new files 'xx-YY-installer.po', 'xx-YY-installer-MARC21.po' and 'xx-YY-installer-UNIMARC.po' remove all new files 6) Create for xx-YY again and try update $ ./translate create xx-YY edit ../../installer/data/mysql/en/optional/auth_val.yml and change one char in one of the translatable values, also edit 'xx-YY-installer.po', translate the same string (in msgstr). Do an update $ ./translate update xx-YY check in 'xx-YY-installer.po' a fuzzy value for the translated value and the preservation of the translation Fix the translation, or add a new one. 7) Create an install dir for xx-YY ./translate install xx-YY Check new dir '../../installer/data/mysql/xx-YY/' Check files on it $ tree ../../installer/data/mysql/xx-YY/ and compare with ../../installer/data/mysql/en/ All installation files must be present 8) Try a new Koha install using this language in the usual way. Check in authorised_values for the translated string. 9) Try create an install dir for an existing language (eg. es-ES, de-DE or fr-FR ) Install dir is ignored and not changed. Comment on attachment 96593 [details] [review] Bug 24262: Translate installer data in YAML format Review of attachment 96593 [details] [review]: ----------------------------------------------------------------- ::: misc/translator/LangInstaller.pm @@ +937,4 @@ > $self->install_prefs(); > $self->install_messages(); > $self->remove_pot(); > + $self->install_installer(); Should not it be placed after remove_pot? @@ +971,4 @@ > $self->create_prefs(); > $self->create_messages(); > $self->remove_pot(); > + $self->create_installer(); Same here. Hola Jonathan! (In reply to Jonathan Druart from comment #4) > ... > > $self->install_prefs(); > > $self->install_messages(); > > $self->remove_pot(); > > + $self->install_installer(); > > Should not it be placed after remove_pot? The order is not relevant in this case, it can be at the beginning, end or middle. The new functions works independently of the old ones, with different target dirs. Created attachment 96626 [details] [review] Bug 24262: Translate installer data in YAML format This patch adds the ability to: 1) Create new translation files from yaml installer files 2) Create installer directory for a given language It will not create a installer directory if it already exists. New (possible) translation files: xx-YY-installer.po xx-YY-installer-MARC21.po xx-YY-installer-UNIMARC.po Needs Bug 13897 (for yaml files) To test: 1) Apply patches from Bug 13897 2) Apply this patch 3) Go to misc/translation 4) Create translation files for a NEW language $ ./translate create xx-YY check new file 'xx-YY-installer.po' 5) Copy ../../installer/data/mysql/en/optional/auth_val.yml into ../../installer/data/mysql/en/marcflavour/marc21/mandatory/ and ../../installer/data/mysql/en/marcflavour/unimarc/mandatory/ remove po/xx-YY*, then repeat creation check new files 'xx-YY-installer.po', 'xx-YY-installer-MARC21.po' and 'xx-YY-installer-UNIMARC.po' remove all new files 6) Create for xx-YY again and try update $ ./translate create xx-YY edit ../../installer/data/mysql/en/optional/auth_val.yml and change one char in one of the translatable values, also edit 'xx-YY-installer.po', translate the same string (in msgstr). Do an update $ ./translate update xx-YY check in 'xx-YY-installer.po' a fuzzy value for the translated value and the preservation of the translation Fix the translation, or add a new one. 7) Create an install dir for xx-YY ./translate install xx-YY Check new dir '../../installer/data/mysql/xx-YY/' Check files on it $ tree ../../installer/data/mysql/xx-YY/ and compare with ../../installer/data/mysql/en/ All installation files must be present 8) Try a new Koha install using this language in the usual way. Check in authorised_values table for the translated string. 9) Try create an install dir for an existing language (eg. es-ES, de-DE or fr-FR ), eg. ./translate install de-DE Install dir is detected and not changed, a note is printed. Created attachment 98506 [details] [review] Bug 24262: Translate installer data in YAML format This patch adds the ability to: 1) Create new translation files from yaml installer files 2) Create installer directory for a given language It will not create a installer directory if it already exists. New (possible) translation files: xx-YY-installer.po xx-YY-installer-MARC21.po xx-YY-installer-UNIMARC.po Needs Bug 13897 (for yaml files) NOTE: updated version adding ability to process multiline fields, discard small ( < 2) strings, and discard strings with pure html, TT or punctuation. To test: 1) Apply patches from Bug 13897 2) Apply this patch 3) Go to misc/translation 4) Create translation files for a NEW language $ ./translate create xx-YY check new file 'xx-YY-installer.po' 5) Copy ../../installer/data/mysql/en/optional/auth_val.yml into ../../installer/data/mysql/en/marcflavour/marc21/mandatory/ and ../../installer/data/mysql/en/marcflavour/unimarc/mandatory/ remove po/xx-YY*, then repeat creation check new files 'xx-YY-installer.po', 'xx-YY-installer-MARC21.po' and 'xx-YY-installer-UNIMARC.po' remove all new files 6) Create for xx-YY again and try update $ ./translate create xx-YY edit ../../installer/data/mysql/en/optional/auth_val.yml and change one char in one of the translatable values, also edit 'xx-YY-installer.po', translate the same string (in msgstr). Do an update $ ./translate update xx-YY check in 'xx-YY-installer.po' a fuzzy value for the translated value and the preservation of the translation Fix the translation, or add a new one. 7) Create an install dir for xx-YY ./translate install xx-YY Check new dir '../../installer/data/mysql/xx-YY/' Check files on it $ tree ../../installer/data/mysql/xx-YY/ and compare with ../../installer/data/mysql/en/ All installation files must be present 8) Try a new Koha install using this language in the usual way. Check in authorised_values table for the translated string. 9) Try create an install dir for an existing language (eg. es-ES, de-DE or fr-FR ), eg. ./translate install de-DE Install dir is detected and not changed, a note is printed. Created attachment 99396 [details] [review] Bug 24262: Translate installer data in YAML format This patch adds the ability to: 1) Create new translation files from yaml installer files 2) Create installer directory for a given language It will not create a installer directory if it already exists. New (possible) translation files: xx-YY-installer.po xx-YY-installer-MARC21.po xx-YY-installer-UNIMARC.po Needs Bug 13897 (for yaml files) NOTE: updated version adding ability to process multiline fields, discard small ( < 2) strings, and discard strings with pure html, TT or punctuation. To test: 1) Apply patches from Bug 13897 2) Apply this patch 3) Go to misc/translation 4) Create translation files for a NEW language $ ./translate create xx-YY check new file 'xx-YY-installer.po' 5) Copy ../../installer/data/mysql/en/optional/auth_val.yml into ../../installer/data/mysql/en/marcflavour/marc21/mandatory/ and ../../installer/data/mysql/en/marcflavour/unimarc/mandatory/ remove po/xx-YY*, then repeat creation check new files 'xx-YY-installer.po', 'xx-YY-installer-MARC21.po' and 'xx-YY-installer-UNIMARC.po' remove all new files 6) Create for xx-YY again and try update $ ./translate create xx-YY edit ../../installer/data/mysql/en/optional/auth_val.yml and change one char in one of the translatable values, also edit 'xx-YY-installer.po', translate the same string (in msgstr). Do an update $ ./translate update xx-YY check in 'xx-YY-installer.po' a fuzzy value for the translated value and the preservation of the translation Fix the translation, or add a new one. 7) Create an install dir for xx-YY ./translate install xx-YY Check new dir '../../installer/data/mysql/xx-YY/' Check files on it $ tree ../../installer/data/mysql/xx-YY/ and compare with ../../installer/data/mysql/en/ All installation files must be present 8) Try a new Koha install using this language in the usual way. Check in authorised_values table for the translated string. 9) Try create an install dir for an existing language (eg. es-ES, de-DE or fr-FR ), eg. ./translate install de-DE Install dir is detected and not changed, a note is printed. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Followed the test plan and all looks good to me.. Signing off OK.. I'm loving this work.. I just had a moment of inspiration though.. what about upgrades? Currently, we add to both an atomicupdate file (which gets put into updatedatabase) and add nearly the same code into various .SQL files (now becoming .yaml files) for install time. I'm now wondering if as a further bug we could add a function into updatedatabase to walk through the tree of yaml files to install translated missing default data at the end of any run of updatedatabase and save ourselves from having to write the atomicupdate and the yaml file for such DB changes? (In reply to Martin Renvoize from comment #10) > OK.. I'm loving this work.. > > I just had a moment of inspiration though.. what about upgrades? > > Currently, we add to both an atomicupdate file (which gets put into > updatedatabase) and add nearly the same code into various .SQL files (now > becoming .yaml files) for install time. I'm now wondering if as a further > bug we could add a function into updatedatabase to walk through the tree of > yaml files to install translated missing default data at the end of any run > of updatedatabase and save ourselves from having to write the atomicupdate > and the yaml file for such DB changes? I think this might get a little too complicated. For example libraries might have removed sample data on purpose, changed or reconfigured it. It would be hard to differentiate. We will want to add a new notice on update, but should respect if a library deleted it etc. (hope I understood correctly). So I think having different mechanisms (triggered for new and for a specific update) would be better. Created attachment 100194 [details] [review] Bug 24262: (followup) admit null values on labels This patch adds handling of null values on translatable labels. Created attachment 100344 [details] [review] Bug 24262: Translate installer data in YAML format This patch adds the ability to: 1) Create new translation files from yaml installer files 2) Create installer directory for a given language It will not create a installer directory if it already exists. New (possible) translation files: xx-YY-installer.po xx-YY-installer-MARC21.po xx-YY-installer-UNIMARC.po Needs Bug 13897 (for yaml files) NOTE: updated version adding ability to process multiline fields, discard small ( < 2) strings, and discard strings with pure html, TT or punctuation. To test: 1) Apply patches from Bug 13897 2) Apply this patch 3) Go to misc/translation 4) Create translation files for a NEW language $ ./translate create xx-YY check new file 'xx-YY-installer.po' 5) Copy ../../installer/data/mysql/en/optional/auth_val.yml into ../../installer/data/mysql/en/marcflavour/marc21/mandatory/ and ../../installer/data/mysql/en/marcflavour/unimarc/mandatory/ remove po/xx-YY*, then repeat creation check new files 'xx-YY-installer.po', 'xx-YY-installer-MARC21.po' and 'xx-YY-installer-UNIMARC.po' remove all new files 6) Create for xx-YY again and try update $ ./translate create xx-YY edit ../../installer/data/mysql/en/optional/auth_val.yml and change one char in one of the translatable values, also edit 'xx-YY-installer.po', translate the same string (in msgstr). Do an update $ ./translate update xx-YY check in 'xx-YY-installer.po' a fuzzy value for the translated value and the preservation of the translation Fix the translation, or add a new one. 7) Create an install dir for xx-YY ./translate install xx-YY Check new dir '../../installer/data/mysql/xx-YY/' Check files on it $ tree ../../installer/data/mysql/xx-YY/ and compare with ../../installer/data/mysql/en/ All installation files must be present 8) Try a new Koha install using this language in the usual way. Check in authorised_values table for the translated string. 9) Try create an install dir for an existing language (eg. es-ES, de-DE or fr-FR ), eg. ./translate install de-DE Install dir is detected and not changed, a note is printed. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Created attachment 100345 [details] [review] Bug 24262: (followup) admit null values on labels This patch adds handling of null values on translatable labels. Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Nice work everyone! Pushed to master for 20.05 enhancement not backported to 19.11.x Bernardo, do yo remember why you added that?
> It will not create a installer directory if it already exists.
379 if ( -d $langdir ) {
380 say "$self->{lang} installer dir $langdir already exists.\nDelete it if you want to recreate it." if $self->{verbose};
381 return;
382 }
On upgrade we want to update the directory.
(In reply to Jonathan Druart from comment #17) > Bernardo, do yo remember why you added that? > > > It will not create a installer directory if it already exists. > > 379 if ( -d $langdir ) { > 380 say "$self->{lang} installer dir $langdir already > exists.\nDelete it if you want to recreate it." if $self->{verbose}; > 381 return; > 382 } > > > On upgrade we want to update the directory. I agree, we want/need to update the files on update. I don't think we could/should handle this differently than other files that are overwritten. |