Hello, Le 25/07/2019 à 23:01, Nick Wilson (Quiddity) a écrit : I’ve got a question concerning that message in the Problems category: ‘Wikidata will be in read-only mode on 30 July from 05:00 to 05:30 UTC because of a server switch.’ For a few weeks, I’ve been disturbed by those messages about the Wikimedia services being in read-only mode because of a server switch, a hardware problem being fixed, a database being moved, etc. This started with Tech/News/2019/23. There I saw the message for Wikimedia Commons. First, I wanted to reuse a previous translation of that kind of message, to try to minimize the effort needed to deal with these recurrent facts, especially for readers (who are like my customers). But there was no suggestion, so I searched for a previous occurrence of this message in previous newsletters. I guess you’ve noticed my HTTP requests in this process; I used the following Bash commands: for i in `seq 1 21`; do curl https://meta.wikimedia.org/wiki/Tech/News/2019/$i 2>/dev/null | grep "You will be able to read" && echo $i; done for i in `seq 1 53`; do curl https://meta.wikimedia.org/wiki/Tech/News/2018/$i 2>/dev/null | grep "You will be able to read" && echo $i; done (Then, in Tech/News/2019/24, I understood that I should provide a more identifiable User-Agent for such requests.) But this returned no previous occurrence! So I thought ‘Well, never mind, let’s write a new translation, and from now on I’ll care about it.’ The same message appeared in Tech/News/2019/25, but initially I didn’t do the translation myself. Then there were new read-only times, especially in #27, #28 and #30. In these newsletters, the message was put in the ‘Changes later this week’ (#27 and #30) or ‘Future changes’ (#28) category. I didn’t notice it in #27, but in #28 this came with the fact that the message was written differently, in spite of Benoît Evellin’s kind message from June 3rd saying that you ‘are looking for solutions to avoid repetitive translations’ (i.e. avoid throwing different message formats for the very same meaning, I guess). Then I noticed the category change and wanted to move the message to ‘Problems’, but then I noticed that the announced date was actually quite far so ‘well, never mind, but let’s provide a longer translation to emphasize the oddity of the far date and the changed category’ (and it says: ‘Please be told that there will be a server switch in 3 weeks; meanwhile, there’ll be a block.’). Then in #30 I noticed the category and the new message format. In opposition to previous formats, this one does not say that the read-only mode is clearly due to the described maintenance process, so I had to provide a new translation to mimic this: the read-only mode somewhat has to do with the process, but we don’t know how. This leads me to talk about the semantical difficulty of previous formats. It says that ‘Such service will be in read-only mode, /because of/ anything’ or ‘/This is to/ do anything’. This is problematic to me because, in principle, maintenance processes do not impose blocking the services. So I understand that it’s WMF maintenance processes which have this flaw. In other words, the blocks are not due to the need for maintenance itself but it’s due to the imperfect processes, and it might theoretically be possible to have maintenance processes which do not impose to block the services. Moreover, from my experience, when you’ve got database servers, you don’t have to replace a server with another one. You’ll more likely setup several servers to store the data. Then one server will crash, so you will remove this one, and add another one instead. The data can be automatically transferred to and exchanged with the new server, and there’s no need to block the service. So software already exists to deal with this (in my case, it was FreeNAS), and each time I am pretty surprised that the so important Wikimedia Foundation hasn’t taken advantage of this software and still gives messages about the need to block for maintenance. Actually this fact didn’t bother me in itself; that’s more the linguistic constructions and meanings that I’m caring about as a translator. You might notice that my translations do not contain this semantical problem, because I don’t want to enter or forward apophenia. I say that blocking ‘is due to fixing’, ‘comes with a server switch’ or ‘is in the process of a server switch’, so it’s part of the process but is not essentially linked to the need of maintenance. So now, in #31, that message from #28 has come back to the ‘Problems’ category. All this is weird, you know! Seeing these ‘problems’ becoming once ‘future changes’ and being expressed using many different wordings with some being wrong… Therefore I can’t help thinking: ‘But what the fuck are they doing with this semantically problematic message?’ I’m not trying to accuse you or to become the new whistleblower. But when I work, I feel responsible for the fact that my work actually emits and supports right things. It’s known that bosses can lead their employees to do bad things, without the employees being knowing at first, and if they don’t care soon enough, then it might be too late for them to fix it themselves. Therefore when I see something sleazy in the scope of my work, I have to ask about it. Initially it was only a quite rare, constantly reworded and semantically incorrect message for that problem in the week; but it suddenly became a message appearing more than one week out of two, possibly for the thing coming in several weeks, and in various categories of the newsletter. So, tell me! What’s the point? Is there something so particular with this recurrent problem? Why is this so hard? Please note that I have many things to do other than my volunteer work for Wikimedia, and that dealing with such oddities takes much time and energy. It’s nearly several hours that I spent viewing and thinking: ‘Oh, that’s weird,’ then ‘Oh, fuck, that’s weird again,’ and finally ‘Oh, fuck, fuck, that’s really weird!!’ But being sure that my work is not used for a devious scheme is more important than anything else. So if the WMF staff could be coherent without me having to explicitly tell them that they must be coherent, it would be much, much better for me. Regards, -- Sylvain Chiron (Frigory)

On Thu, Jul 25, 2019 at 2:01 PM Nick Wilson (Quiddity) < nwilson(a)wikimedia.org&gt; wrote: The text of the newsletter is now final. No new items have been added since yesterday. There won't be any more changes; you can translate safely. Thanks again, and I hope you have a good weekend.