Created attachment 100720 [details] [review] Bug 24875: Remove extra punctuation from tools start page The patron clubs note was ending with .., but patch also removed some single . to be consistent with the majority of entries on the tools page. To test: - Check the tools start page for ending . in the notes - Apply patch - Verify the punctuation is now consistent
I loved the initial typo [U+1F605]
I think there is still one more under Comments > Moderate patron comments.
Created attachment 100910 [details] [review] Bug 24875: Remove extra punctuation from tools start page The patron clubs note was ending with .., but patch also removed some single . to be consistent with the majority of entries on the tools page. To test: - Check the tools start page for ending . in the notes - Apply patch - Verify the punctuation is now consistent Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Created attachment 101351 [details] [review] Bug 24875: (follow-up) Remove ending . from Comments Removes another extra ending . from the Comments section of the tools start page.
(In reply to Lucas Gass from comment #3) > I think there is still one more under Comments > Moderate patron comments. Thx for the sign-off and pointing this out - added a tiny follow-up with the fix.
Created attachment 101523 [details] [review] Bug 24875: Remove extra punctuation from tools start page The patron clubs note was ending with .., but patch also removed some single . to be consistent with the majority of entries on the tools page. To test: - Check the tools start page for ending . in the notes - Apply patch - Verify the punctuation is now consistent Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> Bug 24875: (follow-up) Remove ending . from Comments Removes another extra ending . from the Comments section of the tools start page. Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Patches squashed
Nice work everyone! Pushed to master for 20.05
backported to 19.11.x for 19.11.05
backported to 19.05.x for 19.05.10
Enhancement will not be backport to 18.11.x series.
Created attachment 132495 [details] [review] Bug 24975: Refactor database translations This is an attempt to make the process of translating database strings (like itemtype descriptions) easier for developers and translators. For developers by reducing the amount of code needed to enable translations for a new kind of object (authorised values, letters, news, ...). For translators by providing a single entry point for all translatable strings Table `localization` is replaced by two new tables `l10n_source` and `l10n_target`. `l10n_source` contains the original text while `l10n_target` contains the corresponding translations `l10n_source` is automatically updated whenever an itemtype is inserted, updated, or deleted, so it is always up to date (this is done in Koha::Schema::Result::ItemType). It means that if you delete an itemtype, translations get deleted too. It also means that if you change an itemtype's description, translations are lost (not sure if this should be fixed, since if description changes, translations should probably be changed too) It adds a new subroutine in Koha::I18N, `db_t`, which returns the translation for a given context and string, according to the current language. Translations are stored in memcached (if enabled). So instead of having to declare a new subroutine Koha::ItemType::translated_description, you can write db_t('itemtype', $itemtype->description) In templates you can write [% ItemTypes.t(itemtype.description) %] There's also a new page, accessible from the administration main page, "Localization". It displays all translatable strings and allow to translate them for all enabled languages. Test plan: 1. Before applying the patch, make sure you have translated some itemtypes. Translations should be kept by the updatedatabase script. Before applying the updatedatabase you may want to comment the 'DROP TABLE localization' statement if you want to keep this table 2. Apply patch, run updatedatabase.pl, run update_dbix_class_files.pl and reload starman 3. Go to Admin » Localization, verify that you have your itemtypes and their translations. 4. Verify that the filter is working (it filters on the source column only). 5. Translate some strings by clicking on one of the 'Translate' link, entering some text and clicking on the 'Save' button. You can remove a translation by emptying the text box. 6. Add a new item type. Verify that it appears in the Localization page 7. Change the description of this item type. Verify that the new description appears in Localization page and that the old description is gone 8. Delete this item type and verify that its description no longer appears in Localization page 9. Navigate through Koha (intranet and opac) in multiple languages and verify that item types are translated (if not, please verify in master too, not all occurrences were translated) Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 132496 [details] [review] Bug 24975: Keep the translations, prevent duplicates, and other fixes Translations are no longer lost when you change an itemtype's description, thanks to a new `l10n_source.key` column which must be unique within it's "text group" ('itemtype' is a text group) This also prevent duplicate entries in l10n_source Columns were renamed to better match their purpose: * context -> group * source -> text Use Koha::Cache::Memory::Lite if other caching systems are not available Prepend 'l10n:' to the cache key to avoid conflicts Test plan: 1. DROP TABLE IF EXISTS l10n_target, l10n_source 2. Follow the test plan from previous patch Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 132497 [details] [review] Bug 24975: Fix l10n_source definition in kohastructure.sql
Created attachment 132498 [details] [review] Bug 24975: Fix syntax issues
Created attachment 132499 [details] [review] Bug 24975: (follow-up) Rebase for bug 21946
Created attachment 132500 [details] [review] Bug 24975: Use 'key' for translation lookup This patch switches from using the original text as a key for translations to using a dedicated 'key' field. We also add in a 'fuzzy' flag to denote when the source text has changed and as such the pre-existing translations may be incorrect. ToDo: 1/ Expose 'Fuzzy' on the 'Localization' admin page 2/ Add a 'translation_key' method to Koha::Itemtype to encourage the adoption of a standardly names accessor to get the 'translation_key' from a Koha::Object derived class.
Created attachment 132501 [details] [review] Bug 24975: Re-introduce translated_description accessor method
Created attachment 132502 [details] [review] Bug 24975: Add translation_key method example
Created attachment 132503 [details] [review] Bug 24975: Use translation_key in preference to description
Created attachment 132504 [details] [review] Bug 24975: Add to Koha::UI::Form::Builder::Item
Created attachment 132505 [details] [review] Bug 24975: DBIC Build
Created attachment 132506 [details] [review] Bug 24975: Fix bugs
Created attachment 132507 [details] [review] Bug 24975: Pass transation_key in GetItemsInfo