In T165061#3263807, @Darkdadaah wrote:@Wikitiki89 Do you have examples of a Foo... <-> Foo… article (or with different apostrophes)? The only articles I can think of would be those about the character themselves.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
May 18 2017
May 18 2017
May 12 2017
May 12 2017
Now if you want more details about the actual reasoning, one reason is that on English Wiktionary (I don't know the details of French Wiktionary) we can have an entry for both "Foo..." (with three dots) and "Foo…" (with an ellipsis). And this probably applies to almost any character you might want to normalize. This is one of the reasons we want the redirects working in the first place, so we can control these links by creating redirects in proper places.
It's the result of many community discussions, both past ones and present ones (see this one, for example). Cognate doesn't really do anything that bots couldn't do previously. It is not as though we previously couldn't have done this normalization by bots, but rather we specifically chose not to allow it. The fact that Cognate enables us to generate links automatically without running bots does not nullify our previous decision.
That brings us to another point. We (at English Wiktionary at least) do not want this normalization feature.
May 11 2017
May 11 2017
I am worried that you guys keep misunderstanding the requirements. All we want is to undo the changes for the erroneous feature request T149892, and have redirects be treated as ordinary pages.
Just to clarify, we don't want "colow" on Wiki 2 to link to "color" on Wiki 1. We only want "color" on Wiki 2 to link to "color" on Wiki 1 (and vice versa). In other words we just want redirects to be treated as ordinary pages.
Just to clarify, we don't want "color" in Wiki 1 to link directly to "colow" in Wiki 2, but rather it should link to "color" in Wiki 2 and then the redirect should take place as usual. In other words we just want redirects to be treated as ordinary pages.
Apr 28 2017
Apr 28 2017
Since nobody's specifically mentioned this, it would also be preferable that links are shown from redirects as well (i.e. when they are viewed with "redirect=no").
Apr 13 2017
Apr 13 2017
Note this issue may be made moot by T987.
Apr 11 2017
Apr 11 2017
Maybe this would be a separate issue, but it would also be desirable to be able to add interwiki links from redirect pages as well. These are far less important because they would only be seen if you purposely view the redirect page itself, but they would be useful for a number of reasons.
Dec 22 2016
Dec 22 2016
In T132637#2896573, @TJones wrote:In T132637#2894519, @Wikitiki89 wrote:I can speak for Russian, that folding и/й would not really be that annoying.
I think that in this case, and in most cases, opinions differ, and you are likely to find the full range of opinions out there. At least one native speaker of Russian on the Discovery team (hi, @Smalyshev!) said that folding и/й was more bad than good, and pointed out that yandex.ru, a leading Russian-language search engine, treats confusing the two as a typo. The conversation is buried in Gerrit, unfortunately, but it's in the comments here, on line 136.
Doing a quick search on Google—in English, and with a sample that is not statistically significant, but also not cherry-picked—here's a StackExchange comment pointing out that one is a vowel, one a consonant, and why would you ever confuse the two? And a similar comment on Quora saying they are distinct, though they happen to look alike. Both those comments are probably frustrating to English-speaking Russian learners, who seem to have trouble distinguishing the two. The comparison to i and y in English seems apt.
...
I can't speak for Finnish or Swedish, but I would ask a native speaker before assuming that it would be annoying to them. In Swedish it may even make sense to fold "å" to "aa".
Here's one Finnish speaker who is pretty upset about people ignoring Finnish umlauts—and fortunately for me, complaining in English.
And here are some English speakers discussing the importance of diacritics, with examples of words differing only by diacritics in Swedish, French, Spanish, Finnish and German, with mention of Danish and Norwegian, but no examples.
Dec 21 2016
Dec 21 2016
In T132637#2894355, @TJones wrote:@CKoerner_WMF, @Deskana, & @dcausse, I'm still against the bold version of turning on ICU folding everywhere. It seems that it would be annoying to many users in Russian (и/й), Finnish (o,a/ö,ä) and Swedish (å/ä/a), without folding exceptions in place—so similar problems are likely to exist in other languages.
In T132637#2881770, @TJones wrote:TL;DR: The question for the communities is, I think, which diacritics should not be folded in your language, and is it fair to assume all the others should be folded on wikis in your language?
In T132637#2881246, @Wikitiki89 wrote:In T132637#2881207, @Deskana wrote:Works for me. Thanks! I'll chat to @CKoerner_WMF about contact people today. To confirm I understand, is the audience "wikis in languages where diacritics are used often", and the improvement "searching with diacritics should match words in a more logical manner"?
I would state the audience as "wikis that often contain text in languages with diacritics".
And I would state the improvement with the more frequent scenario: "searching without diacritics should be able to match words that have diacritics".I think @Wikitiki89 is on the right track, though I'd clarify that it's text in other languages with unfamiliar diacritics, and that searching without unfamiliar diacritics should match words that have them.
...
In T3836#2887992, @Deskana wrote:@Wikitiki89 Perhaps you could also help us test this, given the conversation we had on T132637? :-)
Dec 16 2016
Dec 16 2016
In T132637#2881306, @Deskana wrote:In T132637#2881246, @Wikitiki89 wrote:That's a long time. Why should we have to wait another three months?
"Next quarter" could also mean in January, in which case it's just a month or so. We could probably have started a reindex sooner, but it's generally unwise to perform big changes before the holidays. We are interested in making the reindex process faster and less painless to increase the frequency with which we can do them, but that's a long process.
I guess what I'm trying to say is that mid-December is a bad time of year to expect things to move super fast, but we'll get to it as soon as we can. :-)
In T132637#2881282, @dcausse wrote:Mainly because it's still hard for us to track index changes, and doing big batches is easier.
I understand that it can be frustrating, do you have a short list of wikis where it's desperately needed? I can probably do an exception if the list is not huge.
In T132637#2880285, @dcausse wrote:I'd suggest running the reindex next quarter. We could try to contact more wiki stakeholders in the meantime to see if more wikis would be interested.
Dec 15 2016
Dec 15 2016
In T132637#2876944, @dcausse wrote:ICU folding will be enabled on the next reindex batch for english/french and greek wikis.
@Deskana What does the recently resolved subtask mean for this issue as a whole?
Jul 14 2016
Jul 14 2016
Wikitiki89 added a comment to T134423: Deprecate nonstandard behavior of self-closed HTML tags in wikitext..
In T134423#2463408, @ssastry wrote:In T134423#2463223, @Wikitiki89 wrote:In T134423#2463201, @ssastry wrote:In T134423#2462516, @Wikitiki89 wrote:I have often used <span id="foo" /> to create anchors. What would be the new correct way of doing this?
<span id="foo"></span> should work as well.
Well firstly, it's a bit annoying to have to do that. But secondly, I understand from the discussion above that Tidy will strip empty tags like this, even though they do have a purpose.
No, Tidy won't strip tags with attributes. <span id="foo"></span> vs. <span></span>. The former is left behind and latter will be stripped.
All this is in service of replacing Tidy (T89331) and at that point, we will stop supporting self-closing HTML tags.
We still don't have a firm timeline in place for replacing Tidy, but we are beginning to have tools to support this transition so pages can be fixed before Tidy goes away. For example, https://gerrit.wikimedia.org/r/#/c/286928/ provides a tracking category for pages that use these deprecated tags so they can be fixed.
Wikitiki89 added a comment to T134423: Deprecate nonstandard behavior of self-closed HTML tags in wikitext..
In T134423#2463201, @ssastry wrote:In T134423#2462516, @Wikitiki89 wrote:I have often used <span id="foo" /> to create anchors. What would be the new correct way of doing this?
<span id="foo"></span> should work as well.
Wikitiki89 added a comment to T134423: Deprecate nonstandard behavior of self-closed HTML tags in wikitext..
I have often used <span id="foo" /> to create anchors. What would be the new correct way of doing this?
Nov 20 2015
Nov 20 2015
Based on the documentation, "This attribute indicates that pages within this namespace should be treated as the main content of the wiki. Pages within namespaces with the content value set are counted for statistical purposes, among other things." So this would be a matter for further discussion whether reconstructions should be counted as equal to mainspace entries. As it was passed, however, the vote states that the "content" attribute should be false.
Please note the namespace parameters given in the collapsed "technical details" section of the vote page linked to above.
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL