User talk:Cronolio

From Gentoo Wiki
Jump to:navigation Jump to:search

Wiki maintenance

For the job well done maintaining multiple articles you receive this cool red trophy and a high five from Larry the cow! Thanks for all your hard work in translating to Russian as well! --Maffblaster (talk) 22:43, 9 November 2016 (UTC)

Bypassing a redirect

What was your thinking in this edit? Was it was related to translation? Because I don't think there is any good reason to replace a simple link to a redirect page by a more complicated link to a section within an article. - dcljr (talk) 03:46, 24 February 2017 (UTC)

Yes. Redirect is work only for english articles and always when it possible i write link to translated version of article. Like {{c|[[Gentoolkit#euse|euse]]}} >> {{c|[[Gentoolkit/ru#euse|euse]]}}. If you know how to have previous selected language on next page, let me known. --Cronolio (talk) 10:40, 24 February 2017 (UTC)

Would it not be preferable to create "translated" redirects in such cases, e.g., euse/ru containing #REDIRECT [[Gentoolkit/ru#euse]]? That way the translations could benefit from redirects the same way the English versions do. Is there a technical reason this would not work? BTW, in this edit you still have a link to the English euse. - dcljr (talk) 06:43, 25 February 2017 (UTC)

Please explain for me. Why it should have redirect in the first place ? This is some SEO trick ? With some "free and clear" reasons i like to see end point in url. --Cronolio (talk) 07:08, 25 February 2017 (UTC)

Two main reasons:

  1. Convenience, since it's much easier to link to euse (or euse/ru, etc.) when it is first mentioned in an article rather than having to remember (or search and find out) that it's covered in the Gentoolkit (Gentoolkit/ru, etc.) article.
  2. At some point in the future, we may want to have a standalone article for euse, in which case none of the extisting [[euse]] links would have to be changed.

There may be other reasons I haven't thought of. - dcljr (talk) 03:01, 26 February 2017 (UTC)

  1. For 1st reason: in rendered version the name is euse (as it see reader) because i am wrote [[Gentoolkit#euse|euse]].
  2. Another no good reason: no good idea to write in *article*/ru (any language code) because it is reserved for translation. So what happening if in the future we will have euse article (for translation too) and someone forget about this euse/ru redirect?
Ok i just done what you asking me for. But by me this no liked (imho). Sorry if... --Cronolio (talk) 09:22, 26 February 2017 (UTC)

What I meant in #1 was: as a wiki editor, it is much easier to add links to [[euse]] where they are needed rather than having to remember to use [[Gentoolkit#euse|euse]]. Obviously to readers the links look the same. (But that's my point: It's easier for editors and makes no difference to readers.) As for #2, if euse ever gets created as an article needing translation, we would simply delete any existing euse/xx redirects and use the translation extension in the normal way. Are you saying that the existence of redirects called euse and euse/ru will cause problems (now) for translators? How? (I am not a translator, so I don't know much about it.) Isn't the change you made here exactly how you would translate that part of the "Fontconfig" article if euse was a regular article and not a redirect? Why should it be different because it's a redirect? I still don't understand why you don't like using a redirect in this way… - dcljr (talk) 10:29, 26 February 2017 (UTC)

I done this edit and create this page with redirect because you ask me for this. With reason as some search entry point (as i understand).
I think the redirect is a tool for the lazy editors 😀 My total reasons here:
  1. Infrastructure side: i think i save some number of HTTP request/answer for gentoo servers and for reader www-client also. For redirect is work required extra HTTP request/answer.
  2. "Cat in box" and end point of url: if i good reader and i see euse in url i like to see Euse article. If not, it seems to me that I was deceived 😞 "Cat in box" mean the reader never knows what awaits him at the end of. Search for "Schrödinger's cat" on wikipedia also 😉
  3. Translation side and probably main for me: if translator like I am care about national relinking of articles, which under translation. Like link from foo/xx to moo/xx. This translators does the translation for moo like moo/xx. With redirect from moo to boo article by your "redirect way" it is looks like each translator should create a ton moo/xx pages with redirect to boo/xx (sorry for my english. try to understand it)
    So if i will edit foo article and fix link moo with boo (that will work without redirect) i do all the work of other translators, and for myself too. It's much easier way. --Cronolio (talk) 12:38, 26 February 2017 (UTC)
Looks like mediawiki do it via Special:MyLanguage. Example [[Special:MyLanguage/Help:Extension:Translate/Off-line translation|<translate><!--T:49--> Off-line translation</translate>]]. There is also seen a completely different approach to marking for translation. --Cronolio (talk) 18:55, 26 February 2017 (UTC)

OK, let's consider each of these points:

  1. This, I believe, is a complete non-issue. The additional server load of redirects is surely negligible.
  2. Whether your link is to [[euse]] or [[Gentoolkit#euse|euse]], the reader still sees euse and ends up at euse. There is absolutely no difference to readers.
  3. Each translator would create a single [[moo/xx]] redirect for the language they are translating into. (So you just "do the work of" yourself.) This would have to be understood by translators, of course. So I guess my question now is: in the current situation, if a translator comes across a link to [[moo]] in the original article, how do they know whether to link to [[moo/xx]] or just keep it [[moo]] (in the case where moo has not been translated to language xx yet)? Does the translate extension tell them?

As for the Special:MyLanguage feature, I know about that, but I don't think I've seen it used in articles (in the main namespace) around here very much. I'd have to think about that.... - dcljr (talk) 19:58, 26 February 2017 (UTC)

  1. Sometime it slowly work on my desktop. What happening on mobile device i don't know.
  2. I mean if reader move the cursor at url and see what in url.
  3. All in manual mode my friend. I check each link in article.
You can ask maffblaster for translation privileges. --Cronolio (talk) 20:51, 26 February 2017 (UTC)

Would you mind if I asked other users about this and directed them to this talk page? I'd like to get some other opinions on this... - dcljr (talk) 23:41, 26 February 2017 (UTC)

Wiki is opened for all world. My page too. --Cronolio (talk) 00:08, 27 February 2017 (UTC)

I've done it. - dcljr (talk) 10:02, 1 March 2017 (UTC)

Useless edits

Please note that edits like this are completely useless, since they don't change the rendered HTML of the page at all ("<br>" is already rendered as "<br />" by the MediaWiki software). Because they also trigger similar useless edits on translated pages (FuzzyBot can't tell that an edit is useless, unlike humans), such edits should really be avoided. - dcljr (talk) 22:18, 18 July 2017 (UTC)

Please replace the following tag with correct ones: <br> → <br /> Translation plugin don't allow me to save a translation if <br> was used. --Cronolio (talk) 05:12, 19 July 2017 (UTC)
Ah, OK. If it's the software's fault, then nevermind. - dcljr (talk) 06:24, 19 July 2017 (UTC)

'Warning: Display title overrides earlier display title' issue

It seems to me that you know a workaround for this issue as I figured that an edit you made solves the issue. The same issue is present on the other translated versions of the article and I was wondering : Is lowercasing the title the only way to workaround ? and how did you proceed ? --SuwakoMmh (talk) 13:05, 19 February 2020 (UTC)

Hello. My solution was don't add {{Lowercase title}} into tranlation and translate page display title with small first later. Other solution can be add somewhere in translation {{DISPLAYTITLE:title|noerror}}. Ofcource right solution is handle this behaviour inside the template. But not yet --Cronolio (talk) 17:00, 19 February 2020 (UTC)