Talk:Tech/News/init

From Meta, a Wikimedia project coordination wiki

Reducing need for translating constant texts[edit]

When translating the weekly newsletters, the first thing I do is copying over things that don’t change from one week to the other: the lead texts (one distributed and one not distributed), the subsection headers (Recent changes, Problems etc.), and so on. Moving as much of this as possible to templates would greatly reduce the need for copy-pasting and we could work on translating things that have not been translated a hundred times. Creating a template (e.g. {{Tech news header}}) for the not distributed header is pretty easy, but I think even distributed parts could be moved to a template (probably Module:Tech news needs to be tweaked a bit). Thoughts? —Tacsipacsi (talk) 16:27, 17 July 2020 (UTC)[reply]

In theory, when translation memory works, you don't need to copy-paste things, but just click on the right translation that has been saved in the translation memory. This reduces the workload, in theory.
Concerning templates, do you know a way to deliver a multi-lingual newsletter with templates? Do you have the skills to change the module we use so that we can add and remove sections when need? This would be a great help.
Let's discuss about this on the main talk page Talk:Tech/News, where some gadgets improvements have also been suggested!
Thank you, Trizek (WMF) (talk) 10:05, 22 July 2020 (UTC)[reply]
Tacsipacsi: I feel your pain, as I do the same thing for Swedish most weeks as part of my workflow to make sure everything is properly marked for translation and to hopefully catch most mistakes before I ask people to spend their time translating. I started working on moving the non-distributed lead text to a template at least, but then I realised we're making the barrier of entry for new languages and new translators very high: in order to get the newsletter properly translated on Meta, you'd have to pay attention to something telling you to go to another page and translate that template, in addition to the page you're currently translating. This would be even worse when it comes to the recurrent part of the actual newsletter that's distributed. /Johan (WMF) (talk) 18:20, 9 August 2020 (UTC)[reply]
I.e. either way, making it easier for some translators will make it more difficult for other translators. Slightly easier every week for the people who are the backbone of Tech News distribution, or markedly more difficult the first time for those we hope will join them. Or the other way around. /Johan (WMF) (talk) 18:22, 9 August 2020 (UTC)[reply]
@Johan (WMF): How many new language translators are there per week on average? I don’t expect many, so the great barrier still means relatively small net loss. In addition, that barrier is already there with numerous templates already used: {{Tech header}}, {{Deadline}}, {{Tech news nav}} and {{Draft}} (I hope I haven’t missed any). One more template is not a big difference, but if you care much about new translators, you can create an aggregate group from these and add a translate link to the newly created template. Still a different page, but just one click away, and if the link’s language stresses that these are this additional page contains texts that aren’t delivered anyway, translators not caring about how the Meta page looks like actually need to translate less. (Or the current week’s issue can be added to that aggregate group to make translation a one-page process, but that means two more actions—removing last week’s issue, adding current week’s one—every week for the translation admin. I don’t think it’s worth it.) This would mean that senior translators’ life becomes a bit easier, while junior ones’ becomes much easier, win-win situation. —Tacsipacsi (talk) 23:06, 9 August 2020 (UTC)[reply]
Point taken regarding the existing template on the page on Meta, Tacsipacsi. I'm always very concerned about the barrier of entry, and afraid that we're gradually making Tech News more difficult translate for newcomers, but I agree that at least for the non-distributed part that fear got the better of me and my objection probably didn't make much sense. I've created {{Tech News lede}} so {{Tech header|{{TNT|Template:Tech News lede}}}} should work as a solution for that. /Johan (WMF) (talk) 22:39, 10 August 2020 (UTC)[reply]
@Johan (WMF): I would rather include the {{Tech header}} call in the lead template and include it simply as {{Tech News lede}} on the issue pages, in order to keep them short—although that’s just a nuance. And what about creating an aggregate group? (I can create that as soon as I get the translation admin rights, if it’s just too complicated for you.) —Tacsipacsi (talk) 12:28, 11 August 2020 (UTC)[reply]
Tacsipacsi, I really have no opinion there. Feel free to re-arrange the templates if you think your solution is better.
I've not dealt with aggregate groups before and haven't had time to look at it yet, sorry for not commenting on that. Trying to dig myself out of three weeks of accumulated tasks from when I was out of office for a while. (: /Johan (WMF) (talk) 13:05, 11 August 2020 (UTC)[reply]
@Johan (WMF): Okay, I did what I proposed—almost. When assembling the aggregate group, I noticed Template:Tech news/header, which is almost the same as what I wanted to achieve with Template:Tech News lede, except for that it already has many translations, although it used an older text version. I went on using that; Template:Tech News lede can be deleted. —Tacsipacsi (talk) 00:59, 12 August 2020 (UTC)[reply]

I have worked on this issue early summer too, drafting a generic template which could be used for each issue. I wonder if such template would be easily expandable to deliver it with MassMessage. I would gladly welcome your feedback about it, Tacsipacsi, if you have time. --Pols12 (talk) 20:08, 9 October 2020 (UTC)[reply]

@Pols12: As far as I know, this solution doesn’t break the way the newsletter is delivered, although I don’t know how does it work with the plans to ease the distribution. However, as there may be arbitrarily many items in each section, I don’t think this one big template thing would work; I’d rather use something like {{TCT}}. —Tacsipacsi (talk) 00:13, 10 October 2020 (UTC)[reply]
Thank you for your review. Having multiple items is not a problem, we could add 50 parameters in each section, even an unlimited number of parameter with a Lua module. With the new process (thanks for the link!), I am pretty sure MassMessage will look at a section tag and will not expand templates (as currently). So if we use my template, I think it should be substituted on each issue in order MassMessage can send them. This is not an ideal solution because it a supplementary step for Tech New sender which could be avoided. --Pols12 (talk) 16:57, 10 October 2020 (UTC)[reply]
The goal of that task is to have zero supplementary steps, so if any steps remain, the task is not resolved. Speaking of section tag, now I realized that the current hack module uses them, too. Adding a bunch of parameters or a Lua module may make your solution possible (apart from the missing section tags), but I still think it would make the code more complicated. —Tacsipacsi (talk) 10:31, 11 October 2020 (UTC)[reply]

Reducing the need to translate permanent texts (further improvements)[edit]

@Johan (WMF) and Tacsipacsi: Hello, I have a proposal to transfer the header and ending of the weekly TN to templates that will automatically adjust the translation for a given language. I would leave repeated subtitles for translation every week because they are not always the same. I think that such a solution will not be a problem for new translators or languages, and even make it easier because even someone who does not know the language can move the translation to this template, what's more, it's enough that such a translation has been done once in the history of the magazine since its creation. I can see for myself that TN is not always translated in my language, and so it would be at least a headline and ending.--Krzysiek 123456789 (talk) 20:41, 9 October 2020 (UTC)[reply]

As Johan (WMF) explained above, we should avoid splitting translation work between several pages. Using an aggregate group, as proposed by Tacsipacsi, seems reasonable to me. --Pols12 (talk) 08:15, 10 October 2020 (UTC)[reply]
@Pols12: is there somewhere described how such a group works because I cannot find. --Krzysiek 123456789 (talk) 10:31, 10 October 2020 (UTC)[reply]
I haven’t found a page dedicated to aggregate groups, but you can find an understandable definition in Translate extension glossary. This just let you translate several pages from the same Translate page. --Pols12 (talk) 16:08, 10 October 2020 (UTC)[reply]
@Krzysiek 123456789 and Pols12: By the way, I’ve already created the aggregate group back in August; you can translate by clicking the Translate frequently used templates link on this page (or any Tech News issue beginning with Tech/News/2020/34). The group can be viewed (and managed by translation admins) on Special:AggregateGroups. Please note that the current aggregate group description says that these messages are not used in the distributed Tech News issue, which will need to be changed if they will. —Tacsipacsi (talk) 16:59, 10 October 2020 (UTC)[reply]
@Pols12 and Tacsipacsi: IMO your proposal is good, but from what I understand is that in order to add these texts to the aggregated group they still need to be moved to templates. Am I wrong? Krzysiek 123456789 (talk) 23:55, 11 October 2020 (UTC)[reply]
@Krzysiek 123456789: Yes, the texts are still moved to a template. This way the newsletter’s text needs to be translated at two different places, which is more than the current one, but less than what would happen without the aggregate group. —Tacsipacsi (talk) 00:22, 12 October 2020 (UTC)[reply]
@Johan (WMF), Pols12, and Tacsipacsi:I think you can add this to the group that exists for things not sent out. Besides, when it will be in a separate place, it will not hurt as I wrote at the beginning of this thread. --Krzysiek 123456789 (talk) 11:07, 12 October 2020 (UTC)[reply]
I'm not sure what you mean when you say "when it will be in a separate place, it will not hurt", Krzysiek 123456789. Could you explain, please? /Johan (WMF) (talk) 05:52, 14 October 2020 (UTC)[reply]
@Johan (WMF): "when it will be in a separate place, it will not hurt as I wrote at the beginning of this thread." I meant all the things mentioned in the post at the beginning.--Krzysiek 123456789 (talk) 11:10, 14 October 2020 (UTC)[reply]
Sorry for the late reply. I'm still not sure we envision the same thing. Please walk me through a couple of things so that I get what you mean, if you've got the time:
When someone lands on the page, and wants to start translating, potentially being less used to the Translate extension and MediaWiki than you are, how do they get to the translations, if you have them in more then one place? How do you envision this being clear and obvious?
The plan is to use the new MassMessage function to send part of the page, rather than using a Lua module to generate wiki text, so it needs to be a solution that will not send a template or we'll have to keep that template working and updated (in the local language) on all wikis that could potentially get a newsletter. Am I misunderstanding what you're seeing here? /Johan (WMF) (talk) 19:27, 16 December 2020 (UTC)[reply]
@Johan (WMF): Translating at two places is inevitably more confusing than at one place, but it should not be much more confusing. For example, if we change the tiny Translate frequently used templates link to two big blue buttons (e.g. Translate this issue and Translate invariant texts for all issues), it may be even more straightforward for inexperienced translators than having to find the Translate tab. Actually, there’s one possibility to keep things at one place, at least for the current week: create an aggregate group for all stuff used in current week’s issue (i.e. invariant templates plus the Tech/News/YYYY/WW page), and change the Tech/News/YYYY/WW page in that aggregate group each week. This makes your life more complicated (you need to take one more step after initially marking the new issue for translation), so it may be the time to automate the process using a gadget. (Automation makes your life a lot easier, and especially other WMF employees’ lives, who only occasionally deliver Tech News and thus don’t necessarily know the whole process by heart.)
Yes, this solution involves templates, but if MassMessage doesn’t support substituting templates at delivery, then simply it should. Not being able to use templates heavily constrains not only Tech News, but also any other multilingual mass message delivery. The goal is to modify software to fully support delivering Tech News; we shouldn’t use workarounds just because software is not capable of something—it’s time to improve the software! —Tacsipacsi (talk) 20:11, 20 December 2020 (UTC)[reply]
@Pols12, Tacsipacsi, and Johan (WMF): Sorry for replying so late, but I only read the message today. Did everyone at every reply here can mention me, admittedly I have this page in the observed, but on META I am rarely, and the mention pops up on my wiki. @Johan (WMF): I think you understand the idea well, but there was a problem I didn't know about - templates and MassMessage. If I understand correctly then if we apply these templates then as things stand now, on the target wiki instead of the template content appearing there will be a non-functioning reference to its local equivalent? If so, we have two choices either to wait for the success of the global templates movement, or report it in phabricator (I can create one). I am wondering one more thing, what would happen, if before sending the templates, you would change the call to {{subst:}}. By the way, IMO it would be nice if we put a mention about global templates {{🌎🌍🌏}} in the tech news, because this revolutionary solution is almost everywhere gaining support, but is not very popular.--Krzysiek 123456789 (talk) 15:55, 25 July 2021 (UTC)[reply]
@Krzysiek 123456789: Yes, as things currently stand, template transclusions are distributed as template transclusions, so they (almost certainly) break. I’ve already created a Phabcricator ticket asking for ability to {{subst:}} templates (and explained there why it’s impossible to do it with the current infrastructure), but it hasn’t got much love from developers. —Tacsipacsi (talk) 17:24, 25 July 2021 (UTC)[reply]
@Tacsipacsi: I've added there tag of transalted contend maybe that will help. We can find some projects like Tech News where this is needed to build support of this feature. Krzysiek 123456789 (talk) 20:42, 25 July 2021 (UTC)[reply]
@Krzysiek 123456789: ContentTranslation has nothing to do with this issue. What you thought of is #MediaWiki-extensions-Translate, but I don’t think adding that would really help. The issue is not in Translate’s code, Translate can’t really improve the situation, it just spams the workboard. —Tacsipacsi (talk) 21:28, 25 July 2021 (UTC)[reply]
@Tacsipacsi: Actually, you're right, I mixed it up a bit, but I think that if I replace it, I won't clutter the table, because it seems to me that it is best to add a parser function, which will be for example a call to {{mmsubst:}}. Such a call will normally work like a normal template, but it will be triggered when sending mass messages and will insert the appropriate text from the corresponding language version of the template. This is my suggestion for solving this problem, and it could be included in either the mass message extension or the MediaWiki-extensions-Translate extension, although it would be best to make a third one with functions to be run after installing the two above. --Krzysiek 123456789 (talk) 22:12, 25 July 2021 (UTC)[reply]
@Krzysiek 123456789: As far as I know, the Translate extension isn’t, and shouldn’t be, aware of mass message distribution, therefore it can’t be triggered when sending mass messages. Since Translate can’t handle this, it’s just spam on the extension’s (already quite busy) workboard. A third extension won’t be aware of the distribution, either, so the only really viable solution is to build it into MassMessage. —Tacsipacsi (talk) 09:04, 26 July 2021 (UTC)[reply]
@Tacsipacsi: Ok, if you think that would be better, but I do not know why you restored the thread title in phabricator if the problem applies only to multilingual templates, normal substitution of normal templates works, just edit it before sending MassMessage. Krzysiek 123456789 (talk) 12:43, 26 July 2021 (UTC)[reply]
@Krzysiek 123456789: But that’s an extra step. It also makes hard to understand why one template can be substituted, while the other one can’t. And what would you do with templates like {{int}}? Strictly speaking it’s not a translatable template, so if you ask for translatable templates to be substitutable, this one probably won’t be, even though it does depend on the page language. —Tacsipacsi (talk) 21:33, 26 July 2021 (UTC)[reply]
@Tacsipacsi: I agree that it is an additional step, but it works, because there are not many language versions, you can add {{subst:}} tag when inserting a template and you will not forget about it, but if you add it to a template, which is multilingual, it will not work, because the English version will be inserted and then will be copied to other language versions and we need a tag that will work so that when sending, it will substitute the correct version, because it can not be done that when saving, because some language versions may not yet be created. And what you are writing about on the example of int template is a completely different matter, which is also often problematic. This template uses lua module, and here we would need a call that would make the module instead of creating wikitext during parsing, it would create it during saving for the given parameters and change it, something like {{subst:}} only for modules, it would be also useful for templates using parser functions. --Krzysiek 123456789 (talk) 22:06, 26 July 2021 (UTC)[reply]

┌───────────────────────────────────────────────────────────────┘
No, the Lua module is not completely different matter. Module calls and other parser functions can be substituted just like templates: {{subst:#invoke:int|renderIntMessage|mainpage}}Main Page. ({{int}} can’t be substituted right now, true, but that’s just because of how template substitution works: unless <includeonly>safesubst:</includeonly> is added after the opening curly brackets in the template itself, the Lua call is not substituted when substituting the template. But that has nothing to do with the Lua call being a Lua call, and can be easily resolved once MassMessage supports substituting arbitrary templates right before delivery. Or even before that, but it doesn’t seem to be very useful right now.) —Tacsipacsi (talk) 00:22, 28 July 2021 (UTC)[reply]

@Tacsipacsi:Actually regarding the lua modules I was not aware of this usage {{subst:}} thanks for clearing up my mistake. Sorry for writing back today and not earlier, once again please ping me. Wouldn't it be better to report our poppositions to the team responsible for templates and parser? --Krzysiek 123456789 (talk) 17:18, 5 August 2021 (UTC)[reply]
@Krzysiek 123456789: It’s still just spamming a workboard where it cannot be resolved. Only the MassMessage extension is aware of MassMessage distributions. The extension may need changes in the parser (although it seems quite unlikely for me), but even if it does, it needs to be determined from the extension’s side what changes are needed, no work can happen on the parser’s side before that. (Sorry for not pinging, it looks like I forgot it while switching to the old wikitext editor from the reply tool.) —Tacsipacsi (talk) 00:03, 6 August 2021 (UTC)[reply]
@Tacsipacsi I get it. So then can we just wait passively, or is there something that can be done? — Krzysiek 123456789 (talk) 21:40, 7 August 2021 (UTC)[reply]
@Krzysiek 123456789: Not much, apart from implementing the feature ourselves. —Tacsipacsi (talk) 13:03, 8 August 2021 (UTC)[reply]
@Tacsipacsi The only thing I can think of is to create some kind of gadget in JS, because burying it in an extension is not my thing, and I don't even know where to test it, because putting up my own MediaWiki doesn't appeal to me. But such a solution would be strictly tailored to our usage and very labor intensive. I have a question if there is any way, apart from massmessage, to substitute template content like {{subst:}}, but for the right language version of the page and template? Krzysiek 123456789 (talk) 15:17, 8 August 2021 (UTC)[reply]
@Krzysiek 123456789: There’s only one solution that’s possible right now: removing the page from translation, and manually substing templates in each translation. However, it would mean that already-delivered messages cannot be translated through the translation interface, so I don’t consider it a solution. —Tacsipacsi (talk) 18:21, 4 September 2021 (UTC)[reply]

Translatewiki idea[edit]

@Tacsipacsi, Krzysiek 123456789, and Pols12: I've proposed an alternative solution for at least part of this problem, at phab:T288372 ("Add new translation strings for Tech News to WikimediaMessages"). I'm still not sure if all of it is technically feasible/easy to achieve, but it should help to solve at least 6 of the regular steps. (Perhaps we can continue some discussion on that here, to keep the task's own discussion-thread relatively short?). Hope that helps. :) Quiddity (WMF) (talk) 03:03, 11 August 2021 (UTC)[reply]
That would be a much less customizable solution than template one. But for mentionned basic messages, that may do the job. -- Pols12 (talk) 17:09, 11 August 2021 (UTC)[reply]
@Quiddity (WMF): There are three problems with Translatewiki: first, it’s Translatewiki, a separate website, a separate registration is required (and it’s required, anons can’t translate there); second, in MediaWiki messages, translation variables are traditionally only variables, i.e. non-variable link targets should probably not be placed in tvars, but copied over when translating them; third, they {{int:…}} uses the user interface language, not the language of the surrounding text, which potentially results in trilingual result (UI language + page language + English as fallback) instead of up to bilingual (page language + English). —Tacsipacsi (talk) 18:21, 4 September 2021 (UTC)[reply]
@Tacsipacsi: Thanks for the detailed feedback. My thoughts about the 3 problems are: (1) Agreed, the separate site isn't ideal, but we can provide documentation or assistance for getting new translations transferred there (and perhaps we could start off by transferring the strings directly from [1], [2], [3], [4], [5], and [6]), plus it might help encourage more people to participate on that site, which could benefit from it greatly! (2) Understood. I've removed that part from the Phab task. (3) I understand how that could occur, but I'm not sure whether it's an edge-case that is important enough to block this idea.
With that said, do you think it would be worth implementing the idea (i.e. I try to find someone to help set it up technically), until a better solution is available? Quiddity (WMF) (talk) 22:10, 4 October 2021 (UTC)[reply]
@Quiddity (WMF): I don’t think (3) is really an edge case—on monolingual wikis, probably for most people page language = content language (wiki language) = UI language (although there are some who use the same UI language across wikis, which means they have content language ≠ UI language on most wikis), but on multilingual wikis this is often not the case: for example, I use Hungarian UI language on Commons, even when I read Tech News on c:Project:Village pump/Technical (yeah, it’s just two languages, but you get the point). Also, I fear that if we go down this road, it can easily lead that “until a better solution is available” to become a much longer time. —Tacsipacsi (talk) 16:28, 16 October 2021 (UTC)[reply]

Changing the section name - tech-newsletter-content[edit]

At Enwiki's VPT, @Wbm1058 asks for a change to the <section begin="..."/> variable-name, so that it is unique each week again (e.g. "technews-2021-W39")

I think we can do this automagically, but I'm not certain about what code to use. The complexity is, sometimes well-intentioned editors will decide to "initialize the next edition" before the official process gets to it (on Fridays), and they sometimes do a bunch of pages at once. Therefore we cannot use something simple like <section begin="technews-<includeonly>{{subst:#time:Y}}-W{{subst:#time:W|+1 week}}</includeonly>"/>. (because if they did it today, then all the new pages would use "W40".)

There's some complicated (to me) parser-function magic going on in Template:Tech news nav that could do the work, but I don't understand it well enough to adapt it for here...

Questions:

  1. Are there any other problems with this change that I've overlooked?
  2. (and if not, then) Can anyone help fix this?

Thanks! Quiddity (WMF) (talk) 03:00, 27 September 2021 (UTC)[reply]

Oh... Now I re-read the reply and the code here, and I guess this could work?
<section begin="technews-<includeonly>{{subst:#titleparts:{{subst:PAGENAME}}|1|3}}-W{{subst:#titleparts:{{subst:PAGENAME}}|1|4}}</includeonly>"/>
Could someone verify that?
(And also Question.1 still applies!)
Cheers, Quiddity (WMF) (talk) 03:05, 27 September 2021 (UTC)[reply]
Yes, this would work. For example, in pagename of Tech/News/2021/40, year is titlepart#3, week number is titlepart#4, so {{subst:#titleparts:{{subst:PAGENAME}}|1|3}} and {{subst:#titleparts:{{subst:PAGENAME}}|1|4}} is the correct way to get them. And <includeonly>...</includeonly> prevents substitution on the page /init itself. The format "technews-<year>-W<weeknumber>" corresponds to previously used format, e.g. "technews-2021-W12" from w:en:Wikipedia:Tech news/Archive 8#Tech News: 2021-12.
I'd just like to point out that if a hypothetical Tech News issue, that already has a timestamp, is postponed until a subsequent week, then the parameter "begin" will have to be updated manually. —⁠andrybak (talk) 11:58, 27 September 2021 (UTC)[reply]
@Andrybak: Thanks for looking! There's some kind of problem with this... Saving the text above, resulted in init-WM.
I also tried wrapping the includeonly content in {{subst:#time:Ymd|...}} per the existing example on the page-itself, but that resulted in substituting the Error message itself.
I tried reading the help pages mw:Help:Substitution and Help:Recursive conversion of wikitext but I cannot easily understand which examples from there I'd need to follow here. Can you/anyone help? Thanks! Quiddity (WMF) (talk) 19:40, 27 September 2021 (UTC)[reply]
@Quiddity (WMF): Substitution doesn’t work in parser tags, see mw:Help:Substitution#Limitations. As a workaround, I generated the tags with Lua. They appear nowiki’d on the /init page, but should work when substituted on actual weekly issues. —Tacsipacsi (talk) 23:20, 27 September 2021 (UTC)[reply]
Wonderful, thank you!! Quiddity (WMF) (talk) 23:34, 27 September 2021 (UTC)[reply]

Include a link to the Technical Decision Making process on the last line?[edit]

Should the last line of links include something like Learn about the technical decision making process in the bulleted list? I didn't know about it until the survey. Sandizer (talk) 18:32, 25 July 2023 (UTC)[reply]

Hi @Sandizer, thanks for the suggestion. In the past, the TDM has been focused on very technical questions (see mw:Technical decision making/Decision records for examples), most of which require a good familiarity with the MediaWiki-core code and/or related systems and services. It has also been quiet for the last year or so. As such, I don't think it is usually relevant or of interest for editors, and I'd worry about expanding the list of links in the footer. (I'm a frequent reader & writer of "See also" sections, and I'm all-too-familiar with how they can grow out of control!)
However, adding individual topics (as entries within a single edition of Tech News) that are currently seeking feedback is definitely something that we occasionally do, and should do more of in the future, especially once that survey has resulted in an updated process and renewed activity.
I hope that context helps, and that my feedback seems sensible. Further thoughts welcome! Quiddity (WMF) (talk) 19:24, 25 July 2023 (UTC)[reply]