Mon, Jan 15
We definitely should fix this in jquery.uls like you propose. I also propose we get rid of the unused and unmaintained mobile rules while we do it.
What is poor accuracy?
Machine translation is a hot topic. We should discuss it. The big risk here is that the apparent leading solutions are closed source. I don't think that is an acceptable risk in the long run. We need to figure out how to use machine translation in a sustainable manner. We need to ensure we have control over it so that it cannot be taken away from us and that we will be able to support small languages that are not usually supported by commercial entities. We should partner with other organisations doing machine translation engine development. I have a specific proposal for myself to research for my PhD to explore how we can better integrate Apertium in Content Translation so that we enable continuous improvements to the machine translation quality. The easier part then is to open up the cxserver translation API and integrate it into more places, such as structured discussions.
I was supposed to take backups of code and settings from the project and then let it go. Looks like I haven't taken the backups yet.
I won't be able to attend this session because it is running parallel to the language session, so I'll share my thoughts here:
Where can we start listing our thoughts? Personally, I don't like brainstorming sessions as it requires coming up things on the spot – I prefer doing the thinking myself first, doing some research if needed, and use as much time as it needs, before presenting my thoughts.
Sat, Jan 13
Fri, Jan 12
Which machine translation provider does this?
Make sure you have core (OOJS) and CX in latest versions. This method was renamed (a breaking change).
Thu, Jan 11
This is possibly a regression from the changes to improve contrast and to follow the style guide in ULS.
For multiple times I was wondering and almost going to ask some admin whether there was enough tasks or should I put effort in creating more. Some more insight into that status would be nice. I think I decided there will be a CTA if we are seriously running out of tasks.
For Content Translation we are expecting a stable increase in dumps size. See https://en.wikipedia.org/wiki/Special:ContentTranslationStats#global-translations-weekly which seems to indicate that the weekly activity is not currently growing – future improvements to the tool (CX2, translation lists) could bring in some additional growth.
Wed, Jan 10
The wordmarks can have different heights (18px and 22px are used currently). With the jawiki wordmark this issue is not as visible, but seems to still be there. It would also be good to check whether all the wordmarks have the same baseline – if not, then this will be problematic to fix.
Did you use the Timeless skin?
Tue, Jan 9
In theory yes, but one should be prepared to handle the community interactions if it causes changes.
Long shot: maybe T178242: PHP memcached implementation stops working under HHVM?
We are using multiple kinds of separators. Some of them are stylistic, some are not, and I blocked adding a new kind of separator as an translatable message some time ago.
Even though it is small, it looks legible to me. I believe @Pginer-WMF or @Volker_E would know better from design and accessibility point of view whether we should create a new task to improve size and/or contrast.
Mon, Jan 8
So from an UX point of view, the fact that this is the only related button which doesn't act this way is strange.
Which browser are you using? It looks like a rendering issue. There has been recent changes to the images so it there is a good chance it is a regression.
I spoke with Milimetric on Friday. Things were stalled on https://phabricator.wikimedia.org/T170764 to investigate why Amir's old query was not producing the same result as the new query. It turned out the problem was not in the query itself but nevertheless that issue should be fixed now. Some old data was supposed to be purged, I am not sure whether that happened yet. Next steps would be for Amir to ensure that the fix worked and that data is going to end up in the right place(s).
I made 0c604f3. What would be the next step to see how these translations can be used in our Phabricator? Translation progress can be seen at https://translatewiki.net/w/i.php?title=Special:MessageGroupStats&language=fi&group=phabricator#sortable:3=desc
Sat, Jan 6
That is not related to resource loader modules and should not be touched. Like I wrote above only extension.json and some PHP files contain resource loader module definitions (and if you just grep for position you will get false positives).
Message group texts are wikitext. Regular tooltips only allow plaintext. Also, parsing the wikitext into html (and stripping tags) is a performance issue. Non-standard tooltips that allow html are not without their own problems either.
Fri, Jan 5
Yes. This issue was spamming the log so I already put in place the temporary workaround.
It doesn't have any in our configuration.
It was enabled as $wgExtraLanguageNames['ais'] = 'Sakizaya'; # Sakizaya / Amir 2017-05-02 in translatewiki.net by @Amire80.
Thu, Jan 4
I spoke with Ariel. From his point of view we are changing the permanent storage of some data from DB to dumps. The dumps server(s) are already well utilized, and there is no guarantee that data will stay there forever. Even now we keep last 14 dumps only.
Based on today's discussions there seems to be agreement to start with published translations because of a smaller user impact and bigger reduction of size.
Is it acceptable to make the dumps harder to use for end users by splitting them into multiple files over time? Because drafts can change over time, they would need to take into account that newer dumps might have content for same drafts that they need to merge.
- If not, how do we build a reliable way to do incremental dumps that result in files that are not split over time?
- We would no longer use --threshold (because it makes little sense as groupings would appear random to end users) to reduce the number of files we generate. Do we only produce one all2all file or each pair separately? Former would force people to download all the files regardless of the languages they are interested in, latter could lead to us producing too many files.
- How about a case where we would need to purge some content? Currently we can just remove from the DB and remove dumps, because next dump run would generate a clean dump.
- Is monthly frequence enough? We currently do weekly. In my research proposal I argue that we want to build a short cycle of continuous improvements. For that even weekly dumps could be too slow, if the dumps are going to used for that at all.
That's why I propose we do not show the list of subprojects on that page at all.
I am not sure this is a bug:
Wed, Jan 3
Most of these are related to sizing of SVG images in IE, e.g. https://stackoverflow.com/questions/21840551/background-size-with-svg-squished-in-ie9-10 and https://thatemil.com/blog/2015/03/15/sizing-svg-background-images-in-internet-explorer/
(Accidental priority change)
Yes those must be removed. I filed T179563: Lacking mixing for SVG only background images earlier to clarify how to do this. It is not yet resolved, but I suggest we just standardize on this code when PNG is not used:
- LESS files: .background-image( '....svg' );
- CSS files: background-image: /* @embed */ url( ....svg );
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCzwR/pw2jmhVCn8aIgmFoq0ya1qHn4ZSweeWxUTwYl8hyUSvW8JqjWV+pq1SCGebTE4dNiITk9oNTuKaPWUAYlr5RgdNrtSWZ/iiF4EgWCrDB2aeKGE8oFkCiGliF3gAohe3Mpr8doGiXber/GYa8NgFyeAST+K1qKEmRiKEseKDVqW7PYGZqslilAbrvB8MWjR66Enzk02FmlCZQzmz7CnZjjgj9dMlisqOM1BaGUqCFkq1YPYpCXoTf/WPLQ7aN685tak4wslMDUfTqx4vChmKVCQoW5/8IUyK3gk8FhXx+RXGaKx+b6gF4YePCI3G9tJh5jIgNQQodQAnLp1lexRjuA/vW5bXHUU12IDDXIlkRS+GR0PE7pXusEcLUiO/kx4zlYUjjc3QueDNvQjh7wPBWEJ/Rr2TttYzLurC4cHv6W5hhN7pA73LZ61G5ph8x3lfZYsWfpw7R3MKh8LbuT+xbBrvNZAHfpeqlhrRUsWMskBKLu5TYcG8Fv1c2TG3Y8ELYq45ABoXRu5ypKWFvdy0p29qwqsu0CWHxqxIQfSTHoycGYTAgztUzFai01CcDMKPorGdHYaKzB/3npUFoEZ3OEPMbhViOy4xFmUKx0qkI3NZvzwmH/D7Xxp2BkRTKPndsXfKhP/0w5p0ngLk9bmY08Y7akdPbTl5Kiw9VC7w== email@example.com
Tue, Jan 2
Perhaps I should also mention: I had 125% in-browser zoom enabled and I have a 1.5 scaling factor enabled in KDE screen settings.
Another similar issue. The blue highlight is where the middle dot really is according to the browser. There is something weird on the previous non-empty line: if I press down the cursor moves to end of the line. If I keep doing shift+right it takes 4 steps to reach the the position just before A. For some reason there seems to be empty spaces (not sure what kind of spaces) after many/all lines. Maybe copy-paste from one new wikitext editor with syntax highlighting to another one is causing some weird stuff.
Dumps are re-created from scratch every week. Even if we assume old dumps are never deleted (which I believe is not true), people downloading the latest dumps would not have all the content that is available.
I checked the logs and the cause is the same: Exception caught: called before isValid for MediaWiki:Smw-pa-property-predefined sci doi/fr
I'll add temporary workaround if this isn't resolved upstream by next week.
When we start we should also consider doing a general notification to all CX users (tech news or other medium) that we are going to start purging old drafts. We can start from purging only the very oldest ones and gradually decrease the maximum age until we reach the target value.
Data about current ages of drafts would be nice would be nice to have more insight into the numbers. Without numbers I would go for notification after age > 60 days and purge after age > 180 days.
I should set up a maintenance script to run weekly that purges the old articles.
Notifications can be done with Echo.
We can amend cx_translations to have new state purged and update the UI accordingly.
I kept unblocking until it gave an error.
Which parenthesis? I do think it would be good to highlight it, but tab is a general shortcut to move to the next element. So it only works if the textarea has focus, which is usually the case.
Looks like you just need to increase the z-index
It feels to me we are currently having an uncontrolled race to the top. Is it reasonable to ask for project wide guidelines to make things predictable?
Mon, Jan 1
You can reach it by pressing TAB once. Isn't that handy enough?