Last modified: 2014-11-17 09:44:33 UTC
It would be awesome if we could have some option that lets us only run the banner in the languages that we have translations for. This is better than either alternative: * running it in all languages, which gives English text for a lot of people, or * updating the language list every time we get a new translation, which gets really annoying and confusing when we have like 270 languages. Possible solutions: * adding an option in the language selection box that says something like "languages we have translations in", or * adding a clicky-selector (like All, None, Top 10) that automatically selects all the languages we have translations in.
The current language selection interface is solely for targeting a campaign to a particular language project (or projects), it has no relation to what language the campaign's banners are served in (or available in). So for example if you use the interface to target a banner to the French wikipedia, it will still be displayed in English, German, etc, if those translations are available and a user has their interface language set to one of those. So for that reason, the two proposed solutions won't work. The essential problem here is that decisions about what banners are served are decided completely based on campaign information, and campaigns have no knowledge of banner content/settings/translations. I'm not sure there's a good way to solve this without rewriting CentralNotice. Also, there is the question of what should happen in the case that the banner is not available in the user's language. Should they get a fall-back banner? If so, how is it chosen? What if no banners are available in the user's language? Would they get no banner, an English banner, or a notice that translation is needed? It seems that we would need to add another layer of interface to the tool to handle these situations. In the past this problem has been mitigated by added a "Help translate" link to all the banners. Not sure why that wasn't used this year, though.
Aye the help translate link is nice but we found that having links on the banner that weren't the donate link (including the translate link)draw a large (and very significant) amount of traffic away from the donate page (in the 100s of thousands) and that most people who would translate will still find their way to us. Putting it in the meta sitenotice though was a good idea. Regarding the language focusing part. We've essentially ignored the fact that we are targeting projects and not languages (despite knowing the difference and quietly giving Philippe the caveat every once in a while) because the vast vast vast majority of the readers are going to be anonymous and all anonymous readers will see it in the default content language.
Well if we're ignoring the user-language distinction, and you don't want to target languages manually, there's really no point in even having the interface for targeting languages at all. The targeting should just be automatic based on which translations are available. Assuming we wanted to switch to such a system, there are still a few issues: 1. What constitutes having a translation? Would 100% of the messages have to be translated, just 1, something in between? 2. The weights and allocations would no longer be reliable across an entire project type (you might have dramatically different actual allocations for various languages) 3. We still would need to figure out what do to in the case in which no translated banners were available. Do we show nothing?
While I'm not in any way against having an option to target only to where translations are in the system if the option is manual or automatic the choice must be manual. Even when we have lots of translations (for example the Jimmy banner) we will always have multiple times when we only want to be sending that banner to 1 or a handful of projects/languages (in fact most campaigns were like that) or the alternative of sending it to all projects even if we don't have the translation yet. Perhaps I wasn't clear about the user/language distinction. We've basically been working on a content-language = user-language assumption with the knowledge that while it isn't perfectly correct it is for the vast majority of readers because all anons will use the content-language and logged in users should all understand it if we don't have a translation yet. I actually think that targeting by by content-language is far more flexible and better overall, if we have to select manually then that's the trade off. Obviously it would always be nice to have 'lots of options' but each option adds a large amount of complexity into the system. In regards to question 3: Currently we fall back to English which I think is what we want to do. If we're doing the "target by what we have available" option then it would be none but we need to keep the current targeting system at some level and if we do the English fall back makes sense. I don't know if it is only English? I know we have some Chinese dialects that do not appear to be falling back as they should (From what I'm told we have 6 language dialects and we've always used 3 translations but have to manually copy over specific ones to the extra 3 because they don't fall back to zh for example).
I'll give some more thought to this. Perhaps Casey's original suggestions are the best approach. Also, it does appear that fall-back languages do not work in CentralNotice (other than English). There is another bug open about that: bug 17107.
*** Bug 37143 has been marked as a duplicate of this bug. ***
