XSF Communications Team - 2022-10-15


  1. wurstsalat has left

  2. singpolyma has left

  3. singpolyma has joined

  4. emus has left

  5. singpolyma has left

  6. SouL has left

  7. singpolyma has joined

  8. gooya has left

  9. singpolyma has left

  10. Ramiro Romani has left

  11. Ramiro Romani has joined

  12. singpolyma has joined

  13. Ramiro Romani has left

  14. praveen has joined

  15. praveen has left

  16. adiaholic has left

  17. praveen has joined

  18. adiaholic has joined

  19. praveen has left

  20. SouL has joined

  21. neox has joined

  22. praveen has joined

  23. praveen has left

  24. Licaon_Kter has left

  25. debacle has joined

  26. Licaon_Kter has joined

  27. p42ity has joined

  28. p42ity has left

  29. nicola has joined

  30. kikuchiyo has left

  31. Titi has joined

  32. kikuchiyo has joined

  33. emus has joined

  34. jcbrand has joined

  35. wurstsalat has joined

  36. p42ity has joined

  37. p42ity has left

  38. goffi has joined

  39. goffi has left

  40. goffi has joined

  41. goffi has left

  42. goffi has joined

  43. goffi has left

  44. goffi has joined

  45. goffi has left

  46. goffi has joined

  47. kikuchiyo has left

  48. MSavoritias (fae,ve) has joined

  49. p42ity has joined

  50. p42ity has left

  51. p42ity has joined

  52. p42ity has left

  53. kikuchiyo has joined

  54. papatutuwawa has joined

  55. emus

    Hey everyone, first of all thanks for doing and continuing the translations. Yes, I know the problem, but Github is not my choice and I dont see its being chnage anytime soon. So that downside is what will last for the moment. What I could definitely agree to is using .md files prepared for upload. Or if you find a way to push it from some remote platform repo as pep. mentioned In general I would love to see the newsletter translations on xmpp.org directly. Translations are really important as I just saw during my vacations. Many people are not as good in English as we might believe

  56. emus

    Does that sound meaningful?

  57. papatutuwawa has left

  58. emus

    neox, MSavoritias (fae,ve):

  59. gooya has joined

  60. debacle has left

  61. Alex has left

  62. Alex has joined

  63. pep.

    emus, technically, you, or someone else having rights on github would pull, instead of them pushing (since they don't have an account/don't use it)

  64. MSavoritias (fae,ve)

    That was my thought too. But git being the complicated thing that it is i dont want people to learn do it jlst for this. If they dont already know it that is

  65. emus

    Pull it from a codeberg repo?

  66. pep.

    emus, from any repo

  67. pep.

    People would tell "you" where their translations are available

  68. pep.

    I'm curious to know if a platform allows this directly

  69. gooya

    Why not selfhost a gitea instance?

  70. pep.

    Because it's not necessary for this to work

  71. MSavoritias (fae,ve)

    Wouldnt creating a fork also work in another platform?

  72. MSavoritias (fae,ve)

    Or is that what we were talking about 😅

  73. pep.

    I'm trying to write a small thing to show what I'm talking about.

  74. nuron has left

  75. MSavoritias (fae,ve)

    👍 I was going to say blabber has a similar setup of what i am thinking.

  76. p42ity has joined

  77. p42ity has left

  78. p42ity has joined

  79. nuron has joined

  80. pep.

    https://bpa.st/raw/K4VA This still assumes that pulling from github is fine. If that's also an issue, we'd need a mirror somewhere else indeed

  81. pep.

    At least there's no need for an account here

  82. pep.

    thoughts?

  83. MSavoritias (fae,ve)

    I think it can be made easier

  84. MSavoritias (fae,ve)

    Look at this: https://codeberg.org/kriztan/blabber.im In the sense of, if we make a repo mirror like blabber ^ Then we dont need to clone from tne github xmpp.org

  85. MSavoritias (fae,ve)

    But i agree with the idea

  86. MSavoritias (fae,ve)

    I am trying to see how its set up in codeberg now

  87. pep.

    Someone still needs to pull to GH no ?

  88. MSavoritias (fae,ve)

    Ah yeah. So basically i imagine the steps will be: Translator: Pull from translations repo and push there. Website team: Pull the translations repo and merge it

  89. pep.

    Just one other remote then

  90. MSavoritias (fae,ve)

    Yeah. My thinking was tnat we can put all the translations in one place instead of multiple. And the website team has to pull only from there

  91. MSavoritias (fae,ve)

    So codeberg doesnt support it UI wise so its gonna have to be manually

  92. MSavoritias (fae,ve)

    So I made a repo in sr.ht and codeberg both can work. What is the consensus of the approach?

  93. Ramiro Romani has joined

  94. pep.

    Didn't support what? Mirroring?

  95. pep.

    Doesn't support what? Mirroring?

  96. MSavoritias (fae,ve)

    Yeah. Through the UI. I can setup the github repo to point to the sr.ht/codeberg repo and have it as a mirror through the terminal.

  97. emus

    wurstsalat: what do you think?

  98. emus

    I wonder how much additional wir might be

  99. pep.

    It's not integrated into GH, you can't just click a button, so it might be a bit more work if you'r enot used to handling git directly

  100. wurstsalat

    > wurstsalat: what do you think? I don't care. It does not matter which way you choose. All these steps create extra work. Send it via mail, put it in some online pad, push it to some repo, ..

  101. emus

    yeah, but if its intitive

  102. emus

    I wonder if the teams could find someone to just push it to Github

  103. jcbrand has left

  104. jcbrand has joined

  105. patasca has left

  106. patasca has joined

  107. pep.

    https://docs.gitea.io/en-us/repo-mirror/#pushing-to-a-remote-repository codeberg should support this right?

  108. pep.

    I wonder if we can trick it to think github is the mirror

  109. pep.

    And if it fails if the thing differs

  110. MSavoritias (fae,ve)

    There is automated pushing that can be done too

  111. pep.

    Well it's just below in the doc

  112. MSavoritias (fae,ve)

    The reason i didnt propose is because it needs a token and somebody that has commit access to xsf to get it

  113. pep.

    "NOTE: This will force push to the remote repository. This will overwrite any changes in the remote repository!" ah, this is a no-go

  114. MSavoritias (fae,ve)

    The reason i didnt propose is because it needs a token and somebody that has commit access to xmpp.org to get it

  115. MSavoritias (fae,ve)

    Ah

  116. pep.

    We'd have to be careful when pushing, and I don't want to promise no-one is ever gonna make a mistake :P

  117. pep.

    (Even though technically it's not an issue as we can force push the original thing, but..)

  118. goffi has left

  119. goffi has joined

  120. MSavoritias (fae,ve)

    Isnt that more risky than just mirroring? I can take care of the mirroring because i am ok with terminal and every other translator can just use the ui

  121. MSavoritias (fae,ve)

    With sr.ht it would just be an email. No idea about codeberg

  122. pep.

    codeberg is gitea

  123. Licaon_Kter has left

  124. Licaon_Kter has joined

  125. pep.

    Pulling on $otherrepo isn't gonna automate the pushing, you'll need somebody to pull from gh yeah. But gathering everything is one place (for those who don't want to push to gh) would make it less annoying for commteam (than more remotes)

  126. kikuchiyo has left

  127. MSavoritias (fae,ve) has left

  128. Jeroen has joined

  129. Jeroen has left

  130. singpolyma

    Mirror doesn't get you anything in this case. Pulling/merging from any remote is the same one command for the maintainer, that's the beauty of git

  131. singpolyma

    You lose the one click merge in GitHub, but that's always optional anyway and isn't really safe in code repos anyway (though I understand most of those concerns don't apply here)

  132. Alex has left

  133. Alex has joined

  134. pep.

    singpolyma, it gets you that the amount of remotes is reduced, but yeah it's not mandatory I guess

  135. pep.

    (if people coordinate to push to the same place)

  136. singpolyma

    When someone sends a path they can run git request-pull and send you the output so you can't just cut-paste the command to merge it

  137. singpolyma

    When someone sends a patch they can run git request-pull and send you the output so you can't just cut-paste the command to merge it

  138. singpolyma

    When someone sends a patch they can run git request-pull and send you the output so you can just cut-paste the command to merge it

  139. singpolyma

    Or tell you the url some other way of course

  140. MattJ has joined

  141. singpolyma has left

  142. papatutuwawa has joined

  143. singpolyma has joined

  144. debacle has joined

  145. Jeroen has joined

  146. singpolyma has left

  147. singpolyma has joined

  148. Jeroen has left

  149. Jeroen has joined

  150. Jeroen has left

  151. p42ity has left

  152. jcbrand has left

  153. jcbrand has joined

  154. singpolyma has left

  155. papatutuwawa has left

  156. praveen has joined

  157. debacle has left

  158. Jeroen has joined

  159. debacle has joined

  160. singpolyma has joined

  161. praveen has left

  162. praveen has joined

  163. praveen has left

  164. praveen has joined

  165. Licaon_Kter has left

  166. Licaon_Kter has joined

  167. papatutuwawa has joined

  168. Titi has left

  169. singpolyma has left

  170. singpolyma has joined

  171. Ramiro Romani has left

  172. Ramiro Romani has joined

  173. emus

    Maybe the easiest thing would be: - prepare an .md file - Send it to me or let see if there even is a volunteer to organise the file migration - place the file

  174. kikuchiyo has joined

  175. singpolyma

    Sure, if it's just a single new file diffs/commits/merges might be overkill if people aren't used to git anyway

  176. emus

    We have two issues in general I believe: - keep the barrier low (I think we fixed it mostly so far) - keep amount of work low or find more contributors for specific general tasks When it comes to the second point, the setup currently is rather thin. So each new thng should be checked against this. I could believe to also have an official pad, where everyone can participate to translate for a specific language. then push it in the end or ping me. We might just agree on the webtool. What do you think?

  177. jcbrand has left

  178. kikuchiyo has left

  179. gooya has left

  180. kikuchiyo has joined

  181. gooya has joined

  182. MSavoritias (fae,ve) has joined

  183. singpolyma has left

  184. singpolyma has joined

  185. jcbrand has joined

  186. Nÿco has left

  187. Nÿco has joined

  188. Schimon_ has joined

  189. p42ity has joined

  190. MSavoritias (fae,ve)

    Yeah i think it depends how much its going to be used. If we have only 1-2 translations that will not be in github its not worth it to have a whole repo. Might as well send markdown files in this room. If its more interested parties then it starts to make sense imo

  191. p42ity has left

  192. neox has left

  193. jcbrand has left

  194. jcbrand has joined

  195. singpolyma has left

  196. TheCoffeMaker

    emus: Hi ... +1 to having a pad by language and +1 to notify u or sending the PR when it's done ... Because github is a barrier for people that want to contribute but dont want to be part of github

  197. singpolyma has joined

  198. MSavoritias (fae,ve)

    This sounds good too ^

  199. neox has joined

  200. neox

    For the french translation, we already have our own team procedure, based on the LinuxFR redaction platform. So using a pad for french would just make contributions erratic since I would have two locations to check for contributions...

  201. neox

    I prefer to send a fully prepared md file here

  202. debacle has left

  203. debacle has joined

  204. papatutuwawa has left

  205. Jeroen has left

  206. Ramiro Romani has left

  207. Ramiro Romani has joined

  208. papatutuwawa has joined

  209. nicfab has left

  210. debacle has left

  211. debacle has joined

  212. singpolyma has left

  213. singpolyma has joined

  214. singpolyma has left

  215. singpolyma has joined

  216. emus

    Ok, but can you have a description how to join your team procedure? Maybe we can have a wikipage describing where to and how to participate?

  217. emus

    wurstsalat: what do you think about the pads?

  218. emus

    same as before?

  219. Titi has joined

  220. wurstsalat

    emus, adding a .md file by hand is fine by me

  221. emus

    Maybe we start pads, communicate this, but translators who want it on xmpp.org would need to send a .md in the end?

  222. p42ity has joined

  223. MSavoritias (fae,ve)

    Why not just send the .md directly? Would that be a problem?

  224. MSavoritias (fae,ve)

    I am thinking it would complicate thing fith pads and .md plus the github

  225. wurstsalat

    emus, we should let translators decide on how they want to contribute this. Github is highly preferred, since it does not create extra work for Comm-Team. Sending a .md file is ok here, if registering with Github is such a hurdle.

  226. emus

    Yes, but my idea is also to unify, the translation process a bit (if everyone agrees). So we can exchange and guide people there and ensure backup and continous publications. So if we have "one" process for translations we can also communicate this by end of the day

  227. debacle has left

  228. nicfab has joined

  229. singpolyma has left

  230. singpolyma has joined

  231. MSavoritias (fae,ve)

    The "unified" procedure i see at the moment is: Create a markdown file with your translation, sent it to the Comms room.

  232. MSavoritias (fae,ve)

    I agree that it is a high barrier though for new translators. But I am sure the issue is known also

  233. MSavoritias (fae,ve)

    I agree that it is a high barrier though for new translators. Im not sure how many people are even going to bother. But I am sure the issue is known also

  234. Jeroen has joined

  235. Jeroen has left

  236. Schimon_ has left

  237. emus

    I would also make the participation ways more transparent

  238. MSavoritias (fae,ve) has left

  239. p42ity has left

  240. praveen has left

  241. neox has left

  242. neox has joined

  243. Jeybe has left

  244. Jeybe has joined

  245. Nÿco has left

  246. kikuchiyo has left

  247. kikuchiyo has joined

  248. Titi has left

  249. neox

    > Ok, but can you have a description how to join your team procedure? Maybe we can have a wikipage describing where to and how to participate? emus: - neox (myself) translates the whole newsletter as a first pass - neox posts the translation alongside original blocks of text in the redaction platform of LinuxFR website, a well-known place for french free software movement - anybody can contribute then for at least a week to the translation (by correcting, adding, etc) - I review the whole contributions, verifying that it is still with the same spirit as the original, and if needed I let comments to enhance some contributions - When everything's ok, I submit the translation through LinuxFR moderation (where it will be corrected a last time by moderators if needed) and I wait for it to be published, then I send it to news.jabberfr.org - I export the resulting markdown and send it to you

  250. emus

    👍 do you have a xsf wiki account?

  251. neox

    emus: yep

  252. emus

    Would you like to go ahead on and create such a page with this description for the french side? We have a CommTeam page there.

  253. Martin has left

  254. neox

    Ok, will do 👌

  255. Jeybe has left

  256. Martin has joined

  257. Jeybe has joined

  258. Nÿco has joined

  259. adiaholic has left

  260. adiaholic has joined

  261. emus

    Many thanks

  262. papatutuwawa has left

  263. jcbrand has left

  264. nicola has left

  265. SouL has left

  266. SouL has joined

  267. goffi has left