Development IRC meeting 11 December 2024
Jump to navigation
Jump to search
IMPORTANT NOTE: Meeting rescheuled from 4 to 5 December, and then to 11 December 2024 (calendar also updated)
Place
This meeting is held as a video conference using Jitsi:
- The meetings are not recorded.
- You don't have to turn your camera on if you prefer not to be seen; but if you are able to use a microphone it will make things easier.
- To join the meeting, click on the meeting link.
- If you are on a desktop computer, it will open in a browser window. There is no need to install anything.
- To join on a mobile device, you will need to download the Jitsi Meet app (Google Play, Apple Store)
- Supported browsers | Mobile application
- Browsers will ask for permission to use video and audio devices: check or review these settings if you have audio or video issues.
We will use the #koha IRC channel (IRC server irc.oftc.net) to record the meeting minutes, including #info and #action information. Feel free to login there too (if you don't have an IRC client you can use your web browser.)
We will use Hedgedoc to record the meeting minutes, including introductions (formerly #info) and actions (formerly #action) information.
Time
- 11 December 2024, 14:00 UTC Time and Date.com converter for various local times
Agenda
- Introductions (please use "#info" in front of your introduction to have it show up in the automatic minutes)
- Announcements
- Proposed new koha-US forum to connect Koha’s end-users and Koha’s developers - Developing Koha Together: more info in the development chat, koha-US chat; survey (open to 20 January)
- Update from the Release manager (24.11)
- Updates from the Release Maintainers
- Updates from the QA team
- Status of roadmap projects
- Actions from last meeting
- cait: update the wiki to inform that the string freeze dates aren't really a thing anymore.
- oleonard: write developer documentation on the bootstrap 5 upgrade.
- paulderscheid: file an issue for integrating JS15 into QA scripts
- lisette: Add a QA script check for NOTICE1 in the coding guideline.
- paulderscheid: write a draft on date/time related naming conventions for discussion.
- cait: to get in touch with Biblibre on retiring unused mailing list
- paulderscheid: to document the new process for chairing and managing meetings on the Wiki
- General development discussion (trends, ideas, ...)
- Bug 38664 - Tidy the whole codebase
- Review of coding guidelines
- JS strings should always be using double quotes for translation and security reasons.
- tuxayo: additional info: after testing, nothing breaks in template and code sections in .vue files when
- having single quotes in code and the translated string.
- Likely the single quote i18n issue is only for .tt and .inc files because they are duplicated and a search and replace is done on the translatable string which simply inserts the simple quotes and break them.
- Still good for readability to have that guideline in .vue files in code sections.
- joubu: we force tidy for .vue files, and that takes care of that (ie. cannot use single quotes for strings).
- tuxayo: Is there really a security gain? To inject, one could likely just put a double quote or something else relevant to where the string ends up. That wouldn't be unique to simple quotes.
- That looks inherent to doing search and replaces in .tt and .inc to translate.
- If that's right, we might not want to document it as a security reason.
- joubu: koha-i18n takes care of double quote in translations (`KohaI18N::fix_xss`).
- mk: The problem with this approach of just "remember to use double quotes" is that while it fixes the problems right here and now, it takes one slip-up of using wrong quotes and that slipping into main, and the problem re-emerges.
- Was it tested whether cases like
_('Something: "%s"')
won't be broken after changing them to_("Something: \"%s\"")
? Will the string still be matched?
- Was it tested whether cases like
- mk: Ideal but hard solution: match
_('')
and_("")
(to recognize them as in-JS usage) during translation composition and handle them accordingly before the fallback raw string match. But how to do it? - mk: Fallback solution: fully migrate all JS
_()
usage to runtime (from messages-js)__()
(double__
), to ensure the old method is never used in JS anymore. It's just a few thousand occurrences :)- This is nice, but it might still match translations from regular messages file (if there's the same string in both messages and messages-js). Ideally long-term eliminate all such inline <script> tags from .tt files if they use any translations completely, eliminating one of the root causes of why this is an issue, since .tt was kinda meant to be for HTML, right?
- Or don't match random strings in .tt, but that'd have to make everything use the
[% t('A translatable string') %]
syntax instead, right? In fact such a syntax could be used to embed JS strings without XSS possibility too if it was ran through escape func if someone really wanted... - So honestly, if you just switch to using either
[% t('A translatable string') %]
in .tt (for HTML) or runtime JS__()
and stop matching random strings in .tt (which is not sane), then the issue would be solved too.
- mk: UPDATE, I created RFC and bug for my proposed changes, would be nice to mention them too:
- RFC: Translation_in_templates_fix_RFC
- Bug: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38618 (dummy bug for now)
- tuxayo: additional info: after testing, nothing breaks in template and code sections in .vue files when
- Update of coding guidelines to remove reference to any jQueryUI widget beside autocomplete. Add note about jQueryUI deprecation.
- Clarify the use (mostly non-use) of alert() in coding guidelines or Interface patterns.
- After discussion in https://chat.koha-community.org/koha-community/pl/nuk353y6e3dr5f1eqt8xk9utac
- mk: If you consider toasts rather than modals, keep in mind comments from here: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37939 (or don't consider toasts)
- Add coding guidelines about updating Hea list of system preferences when a new system preferences is added? Bug 23849
- JS strings should always be using double quotes for translation and security reasons.
- Any other business
- Set time of next meeting
Apologies
Please list your name here if you would like to attend but cannot make this meeting
Minutes
* Minutes: https://koha-hedgedoc.servers.llownd.net/Development_IRC_meeting_11_December_2024