[14:32] hey there, could anyone help me figuring out how ubiquity translations are working exactly? [14:32] in particular the UI from gui/gtk/ubiquity.ui [14:32] those are not in the translation template and the file is not in the po/POTFILES.in [14:33] it looks like debian/ubiquity.templates and debian/ubiquity.templates-imported have some of those strings [14:33] but I couldn't figure out how those files are used/updated and if the strings are supposed to be common [15:08] seb128: strings are extraced into debian translation templates.... one place for it to be stripped, the otherone that persists and remains in the package, and then translations are queried from debconf and applied. [15:08] xnox, how does one do the 'extract to template' bits? [15:08] seb128: but like some strings are "reused" from other places [15:08] seb128: ./ubiquity/i18n.py [15:09] seb128: not sure i remember. I try not to introduce new strings =) [15:09] oh my [15:09] :) [15:09] seb128: i thought something like cd po/; make something =) [15:09] there was a trick to it, but I don't remember what it is [15:09] def some make command [15:09] that does extract thins from files listed in po/POTFILES.in (mainly the .desktop) [15:10] the po/ target [15:10] but gui/gtk/ubiquity.ui isn't handled like that [15:10] cjwatson, ^ do you maybe remember? [15:10] seb128: oh [15:10] I think there's another .pot file for that [15:10] seb128: i think ubiquity.ui one has to manually edit in the template with the matching template id under ubiquity/ [15:11] unless that was the wrong way to do it. [15:11] That does not sound like a thing I would have done [15:11] it does look like it [15:11] cjwatson, no launchpad template is mentioning gui/gtk/ubiquity.ui atm [15:11] so it does look like the same strings do end up in debian/ubiquity.templates by some magic [15:12] or manual work [15:12] I can't really make sense of it though :/ [15:12] I'm just trying to fix https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1731070 [15:12] which in principle is easy, get '_Skip' in the template [15:12] or I could rename it 'Skip' which is existing/translated [15:13] but that would be a keyboard navigation regression [15:13] Is _Skip a GTK string? [15:13] let me look [15:14] Because if so you may just need to do 'make -C debian/imported-po update' with some variables set that it will tell you about [15:14] no, it's not [15:15] :( [15:15] it would be nice if it was, cause then the translation would be there for all languages [15:15] OK, so it does look as though somebody updated the string for progress_cancel_button in ubiquity.ui without modifying debian/ubiquity.templates [15:16] I guess it's possible those need to be kept in sync manually; maybe I couldn't figure out a better way to do it [15:16] is there some architecture document somewhere describing how those things are supposed to work? (I tried to look for one but without real luck) [15:17] I fear probably not [15:18] cjwatson, ok, so basically the fix is to edit [15:18] Template: ubiquity/text/progress_cancel_button [15:18] Type: text [15:18] _Description: Skip [15:18] to add the _ [15:18] right? [15:18] I think so [15:18] Unfortunate but there you go [15:19] Would be nice if that were automatically extracted, which is surely possible [15:19] I don't understand ubiquity enough to know why that's not going through standard gtk translations/listing the .ui in po/POTFILES.in but I guess there is a reason [15:19] But maybe nobody wants to put that much effort into ubiquity [15:19] right, I doubt we are going to do that sort of changes on ubiquity at this point [15:19] I think it may have made sense in 2006 [15:19] Otherwise, apologies [15:19] cjwatson, xnox, cyphermox, thanks for the replies/help! [15:20] xnox, good news is that this string exists/is translated in nautilus so we can probably just re-validate the translations which already exist on launchpad [15:21] seb128: possibly we may want to import from that po/mo/etc ? [15:23] xnox, I think launchpad does know about the string existing in another template and then suggest the existing translation in the web UI [15:23] so we just need translators to go check and click the approve button [15:23] should be easy enough [15:23] seb128: yes, but then one has to click on them, and rexport, and reimport, and reupload ubiquity [15:23] well, you will need an export/import anyway since it doesn't use langpacks... [15:28] seb128: well, i have simply made ubiquity upload with a new templae and hand edited po files to include new string, base on prefetched processing using msggrep tooling before. To speed up coverage. [15:28] instead of doing ubiquity upload with 0 translations; then wait; then export; reimport 30 translations. [15:28] i did the upload with new string & 25 translations in place. [15:29] xnox, you mean in the past, or you just did for that _Skip one? [15:29] but yeah, possibly a false optimisation [15:29] seb128: in the past when introducing a "new" string which has common translations elsewhere. [15:29] we have been living for ever with that string not translated, I don't think it's a big issue for 19.10 [15:29] ah [15:30] but if someone want to do the msgmerge dance I will not stop them ;) [15:30] i vouched to never introduce new strings after it [15:30] good choice :) [16:47] xnox, cyphermox, https://code.launchpad.net/~seb128/ubiquity/+git/ubiquity/+merge/373977 if you feel like reviewing/merging. The previous string was not matching the .ui so not translated so it doesn't regress translations and should be fine to include if we do another upload (which we will probably do before release)