Ongoing feedback summary:

• T207361: CX2: Clicking on the source paragraph doesn't start a translation in the corresponding target paragraph
• Q: Will cx2outreach (T207031) be used for promotion similarly to the pop-up on editing pages in CX1?

I'm not sure I understand the steps to reproduce. Point 3 as it's written now requires reopening the selector, so everything is rebuilt anyway. It's possible that I misunderstand it.

In T207139#4669791, @Mvolz wrote:

For one, it's not possible to add maps in the GUI at all. It's only
possible in manual. The maps param is used by citoid and other third party
gadgets like prove it and some wikidata ones. Supporting it would be good
but a little more complicated. Basically you need the full fledged GUI JSON
editor for it because it can have a more arbitrary structure compared to
other params.

Resolved in the redesigned dashboard. Correct lang and dir are applied now.

I just tested, and it no longer happens in CX2.

In T189982#4654356, @D3r1ck01 wrote:

@Amire80, invitation sent to your email gotten from: [[mw:Special:MyPage/contact]] :)

Signed up at https://www.mediawiki.org/wiki/Google_Code-in/2018 . Is there anything else I need to do?

Thanks! Looks good to me. @Arrbee and @Pginer-WMF - can you please verify?

OK, so if I understand correctly, it's probably easy, but may require some intervention from @Milimetric or somebody else from Analytics. Looks like what needs to be done is the following:

1. Change the query to select the last day of the week instead of the first day. Done in https://gerrit.wikimedia.org/r/465152 , needs review.
2. Delete the current TSV files.
3. Deploy the change and let the data for the previous months be recreated.

In T155368#4647725, @eranroz wrote:

However I can barely see some usages for lexams where a word in ancient Hebrew have different meaning then modern Hebrew - however in such cases there is no option to have the distinction between Biblical Hebrew and Mishnaic Hebrew as they are both hbo?

In T205197#4646529, @matmarex wrote:

In T205197#4646509, @Amire80 wrote:

But why is it a bad practice? Till now I haven't heard a single really good explanation of why is it bad, or why using a template that does nothing but call a module is good.

The explanation that convinced me is that it allows the implementation to be changed to something else than a Lua module. For example, if a "native" parser function to do whatever the template/module does is implemented in the future, changing a template to use it is easier than changing a Lua module.

In T205197#4646520, @stjn wrote:

In T205197#4646509, @Amire80 wrote:

But why is it a bad practice? Till now I haven't heard a single really good explanation of why is it bad, or why using a template that does nothing but call a module is good.

Other than one more word, #invoke:, calling a Lua module is not more complicated than calling a template.

Because modules practically always represent abstractions and templates are ‘front-facing’ interfaces that can be improved on top of those abstractions as much as users would like.

Ah, thank you. This is a good pointer.

In T205197#4646487, @stjn wrote:

I guess that the reason for this is that there is an assumption that modules are usually not used directly in articles, but are only used internally in templates. I suspect, however, that this assumption is not quite true: searching the main space of the English Wikipedia for insource:#invoke finds quite a lot of direct module invocations.

But how can we be sure that supporting this behaviour is not supporting a really, really, truly a bad practice?

If the articles describe the same thing, then the items should indeed be merged. (I'm really not sure that they describe the same thing because I'm not a doctor.)

@bmansurov asked me to chime in, and since I've been obsessed with interlanguage links for many, many years, I'm happy to help :)

In T189475#4630077, @Milimetric wrote:

Is this blocked on picking a database?

This is a bit strange and inconsistent... Why, for example, does the Saraiki Incubator main page use the Persian numbers?

Is there a reference that says that Saraiki uses Arabic and not Persian numbers?

Is this still relevant?

@Aklapper, I added a checklist of extensions that need conversion. As far as I see it, two patches for each of them can each count as a good complete GCI task (one Gerrit patch for the translatewiki repo and one Gerrit patch for the extension repo). This task lists all the steps and links to several examples. Is there anything else that should be done here for GCI?

This looks better now than it looked when I filed the task: The translation in progress is loaded, but the first paragraph is missing, and I'm pretty sure that I did translate it. Also, I see these errors in the console in debug mode:

In T199342#4613098, @Neil_P._Quinn_WMF wrote:

@Pginer-WMF, @Arrbee, T194641 and T194647 require us to have "pre-publication" data about when users started, continued, and published their translations. As far as I can tell, the only source for this data is ContentTranslation events.

Looks like it's yet another issue blocked by T126900 :(

There should probably be a way to comprehensively document all Lua functions, including internal ones, that are not directly invoked by pages or templates. Something like JSDuck for JavaScript or Doxygen for PHP.

The whole module has long documentation, yes. Some templates have long documentation, too. However, TemplateData is not the whole documentation, but just a brief description of each parameter.

In T205197#4609754, @valerio.bozzolan wrote:

That's a smart question. For more background about this topic let me say that whenever a template may be implemented by a Lua module, a Lua module can provide much functions and so can provide the implementations for multiple templates.

For an existing template one can say that people are accustomed to using it. Bit if a new module is created, is there a reason to wrap it in a template? Isn't it superfluous?

Yeah, so that's what I don't get: //Why/ is it "somehow more appreciated to have an additional abstraction layer"? Is it actually good?

It's indeed the ad blocker! Thanks.

Forgot to mention: The slashes issue is not a CX problem, but a content formatting problem. There should be a global unified way to format code examples on all wikis, and it should include correct code direction setting.

I'm closing this:

The icons in question don't have tooltips.

To see this:

1. Go to https://en.wikipedia.org/w/index.php?title=Special:ContentTranslation&version=2
2. You may be asked to enable the Content Translation beta feature. Do it. ("Try it now!")
3. When the "Translations" dashboard is opened, click the "Suggestions" button at the top.
4. Examine the rows under "Suggested pages". Each of them has a star icon and an X icon in the right-hand end.

Here, again, by convention, everything that is valid in Biblical is also valid in Modern (some of these words and forms are actually common in modern written Hebrew and some aren't, but all are valid in theory). All modern Hebrew dictionaries include usage examples from the Biblical language, and a comprehensive Hebrew dictionary includes all the Biblical words. Marking a citation as coming from the Bible is functionally equivalent to marking it as Biblical Hebrew (does Wikibase Lexeme have usage examples?)

In T153964#4592777, @Addshore wrote:

@Amire80 Are there any exceptions to the rule that all i18n messages should be prefixed with some extension prefix?

Well... "Supercalifragilisticexpialidocious" is a somewhat extreme example, not because it's long, but because it's questionable that it's a standard English word. (I'd say that it absolutely is, but some people may disagree.)

I don't think I understand what X and V mean here.

In T204492#4588220, @IKhitron wrote:

Sure. And also, there are words where you want to hyphenate in places you decided, not the auto-hyphenation mechanism. So adding this manually will be very helpful.

­ is very manual. I can thing of a much simpler way to do this: set CSS hyphens: auto; on the title, and perhaps on other parts of the article content. Yes, there are languages for which auto-hyphenation hasn't been developed yet, but this work is being done.

As far as I can see, this was translated by @Awangba_Mangang. If I misunderstand something and it still doesn't work, please reopen this task.

Is it the same problem with https://commons.wikimedia.org/w/index.php?title=File%3AWilhelm_Gesenius_Hebr%C3%A4ische_Grammatik_(umgearbeitet_von_Emil_Kautzsch).pdf&page=328 ?

Um, I'm not sure whether I'm in a conflict of interest here or not...

Hmm... There are several considerations here.

Thanks for the comment. I updated the description at https://language-reportcard.wmflabs.org/cx2/ . Notice both "Translations" and "Translators" tabs.

I had a great meeting about this with @JAllemandou and @mforns yesterday. Here is the summary.