Talk:Current events
From Avisynth
This page link to the following page :
http://avisynth.org/AviSynthInOtherLanguages
That it-self link to
http://forum.media-video.com/show.php/act/SF/f/7296
which is not of any help. This is only advertisement. I think we should remove it. vital 04:52, 17 May 2007 (PDT)
- Old wiki pages can't be edited. Have made the link to point to a page in the new wiki.Gzarkadas 10:25, 17 May 2007 (PDT)
[edit] vandalism
How we can block vandal or robot who deleted or modified some topics last days (5-7 june 2007)? admins, please try check (and block) IP. Fizick
- For the moment the incidents are few, but it may as well someone tests a robot for later launching a full attack (the random user names are suspicious).
- Is it possible to ask in the registration and login screens the user to enter an additional code shown in a graphic (an image) as many sites do to ensure there is a human and not an automated script behind? This, together with other possible measures:
- an expiry date say of 1-2 days for the "remember login on this computer" feature
- a limit on the per hour transactions (page edits) allowed for users
- an automated blocking of any user not in a known-good-users list that initiates many transactions
- would make using robots harder (and limit the needed revert operations). But how easy (or hard) is to implement those? Gzarkadas 15:27, 7 June 2007 (PDT)
Waiting for catcha at user registration http://www.mediawiki.org/wiki/Manual:Combating_spam http://www.mediawiki.org/wiki/Extension:ConfirmEdit Fizick 00:57, 12 June 2007 (PDT)
[edit] Localization page names
IMO, the current localization naming policy (adding /de or /fr or /pl to page name) is not optimal. It is convenient for English man (admin) to see how to translated some page. But it is not very convenient for forein readers.
And this policy is already violated by some translators. They use translated page name as page name. It is convinient for forein readers, but it is not good for wiki structure.
1) In my opinion, we should use prefix mark for all forein language pages instead of suffix, i.e.:
http://avisynth.org/mediawiki/pl/Strona_główna instead of current: http://avisynth.org/mediawiki/Strona_główna
2) But in my opinion, to be cleare, such page must have some comment in its text : translated from 'english page URL'
Fizick 13:22, 12 June 2008 (PDT)
- To be clear, I'm trying to comply with both policy and convenience, by naming page in native (polish) language and putting a redirect on [english_version]/pl. I agree though, it's making a mess in the current form of wiki structure. Thar 10:56, 17 June 2008 (PDT)
- I see someone has started changing those names, Strona główna now redirects to Main Page/pl. Since no consensus has been reached here and no rationale for that change given, I'm going to roll it back to previous state. Thar 02:29, 16 July 2008 (PDT)
Wikipedia uses a prefix at the base name and a localised main page url (ie [lang].wikipedia.org/wiki/[localised page]); I believe some of the translators are inspired from this scheme. However, it is difficult to use such a scheme in our wiki because there is a large part of the documentation that is and will remain inherently english. I mean the filters, functions and plugins names (and, consequently, wiki pages). Translating them will pose problems to locate information (since the user sees the english name in the script) while keeping them in english will make the translated-url-space bilingual and a bit confusing maybe.
In view of this, I propose to keep the [base url in english]/[lang-id] scheme as the default, because
- it facilitates structure, and
- it may later give us the ability to select and serve lang-specific page using the browser's credentials if the user enters only the [base url in english] (which I find useful and technically it is easier to do when the lang-id is postfixed to the url).
Any translator then that deems appropriate to provide localised urls, can do so by using redirection pages. Existing localised-url pages can be engineered in reverse to save time to convert to default scheme (ie make the default en-url page redirect to the localised-url page).
Gzarkadas 14:53, 17 July 2008 (PDT)
- Your proposal is logical and well argumented. Would you mind if I ask, what are the shortcomings of [lang].avisynth.org scheme? Thar 16:08, 17 July 2008 (PDT)
Anyway, we must not use English namespace for non-english pages! Bad example is: http://avisynth.org/mediawiki/FrameServer It must be fixed (by deleting this and creating correspondent ".../de" page. Fizick 22:39, 17 July 2008 (PDT)
- I agree with the proposal of Gzarkadas and the comment of Fizick. Wilbert 01:48, 18 July 2008 (PDT)
Hi all,
I made a review of the (so far) localised pages and the ways that a wiki editor can search for a group of localised pages and together with some thinking about what we want to achieve in the long term by the localisation of the documentation, I have reach to a sligthly modified version of my initial proposal (the rationale follows, when needed, each part of the proposal intended).
- Use the prefix url-notation proposed by Fizick in all wiki pages (with lang in all lowercase, as it is accustomed for urls).
- Using the postfix url-notation makes searching for lang-specific pages difficult. The wiki provides only for prefix search. The prefix notation is far better in this respect.
- My opinion for easier serving of content with the postfix notation was based on the way Apache can treat file-based pages. But the wiki is powered by an sql-database, so this assumption does not hold. In addition, the prefix notation can also facilitate language selection at the future (if we move english pages to the /en/ sub-wiki and make a stub "select language page" for each old url).
- What we would actually need is the [lang].avisynth.org/mediawiki/[page], ie splitting each language sub-wiki in sub-domains; but this is not feasible at this moment and since we are trying to define a policy now, using the avisynth.org/mediawiki/[lang]/[page] is the next best available option.
- Use (after the mandatory prefix at the start of the url) localised urls for all pages that do not document an AviSynth script-language element (currently a builtin or external filter / plugin). This also includes the main page.
- Most of our translators already place links in their native language. At the end, this is rational, since the wiki facilities (surrounding text with [[ ]]) make this the natural way to create content; everything else requires more work (switching language at the keyboard, placing | and adding description text to the link, etc.).
- Trying to keep the urls in english places thus an unessecary burden to translators; this in turn will result in less volunteers. Therefore we should only keep in urls english terms that make sense to keep - the AviSynth language elements and international terminology.
- We can't anyway effectively control the parts of the wiki that we do not understand the language that they are written in. What we actually need are people in charge of them to maintain and develop. Posing uneccessary restrictions, will not help in that way.
- For filters/plugins, the part of the url that refers to it must have its name as is defined at the AviSynth script language (ie in English). The same as above must be applied to all international terms that are listed to the Glossary (and elsewhere, if any), such as for example RGB.
- The lang prefix at the start of url is enough to distinguish between different lang versions.
- For the main page, due to its special role as an entry point, provide a [lang]/Main_Page redirect, so that foreign users can reach it without the need to actually know the language.
- Since we are opting for full localisation, fallbacks to using en-urls for a term that can be localised must be avoided and corrected if happen.
- Using redirect pages to provide the [lang]/[original english url] can still be applied but we should leave it optional.
- Most of the translations at the offline docs consist of internal and external filters; thus there is little if any need to enforce an english url alternative to the native url for pages not describing filters.
- In the future, there may well be the case that a non-english sub-wiki can contain pages that do not exist at the english wiki. Which is the master and which is the copy then?
- If it is needed then it will be relatively easy to apply it. The bulk of the documentation is filters; rest topics are quite less in volume.
Please post your comments.Gzarkadas 16:06, 19 July 2008 (PDT)
- Just to add that using redirects with all-en urls allows to type the url for any page (localised urls do not work that way, due to being Unicode). Thus we should probably have them as mandatory and not optional. Gzarkadas 13:01, 22 July 2008 (PDT)
- If other editors do not have any objections and Wilbert approves the scheme proposed by you, I'll start using it right away. Thar 16:07, 22 July 2008 (PDT)

