Re: Fwd: I'm still alive!/ notes from FAQ review on apache server

Looks much better.

The definition of Lang. Negotiation should add "accept-language" in front of
the word information, so the definition can be read and understood w/o reading
the rest. Also, we need a way to distinguish/highlight definitions, so they are
easily recognized as such.
They should also be targets for links.

I guess I could put it in the glossary I started if we are going to continue
that effort.
Or we can start a page for terms used in the faqs. The page could be 
called FUD frequently used definitions... ;-)

I think you might want to give more weight to the suggestion of using a lang
other than english as the default.

More later.
tex

Richard Ishida wrote:
> 
> I've been making edits. Notes below, if you're interested...
> 
> > Discussed the Apache language negotiation faq.
> > Here are the comments I remember, since the detailed notes I
> > took were promptly, accidentally vaporized after the call....
> > Please check that this reflects your comments completely and
> > accurately.
> > Apologies in advance.
> >
> >
> > 1) The question should not reference content authors, as they
> > may not be the ones to address negotiation. Administrators
> > can also take advantage of these commands. (I do note in para
> > 3 and 4 the faq presumes the author, and distinguishes privs
> > coming from the admin.)
> 
> Changed.
> 
> >
> > 2) The faq mentions multiple approaches but then proceeds to
> > discuss only one (multiviews). It was suggested that we
> > clarify that within the faq and also in the question. Wording
> > of the Q (to resolve pts 1 and 2), could be something like:
> >
> > How does one set up language negotiation via Multiviews on an
> > Apache Web Server?
> 
> Changed.  It's a little long now, but avoids assumptions about understanding
> 'language negotiation' and adds reference to multiviews.
> 
> Had I made the call, the odd one-sidedness was one of the key things I
> wanted to discuss - I think it works much better now.
> 
> Various changes made to the text to accommodate the focus on multiviews
> only.
> 
> >
> > 3) Answer, para 1
> > We didn't think that the lang. neg. should be presented as an
> > either/or choice, since in the previous meetings on this
> > topic we considered it was likely people would do a combined approach.
> 
> It isn't.  It says 'in some cases'.
> 
> >
> > 4) The term "language negotiation" should be defined. Some
> > readers may not know what it is, and even though it is a
> > standard term in the industry some of the participants didn't
> > think it was apt. It isn't really a negotiation since a
> > request is made, and some response is given and end of story...
> 
> Done, in the background.
> 
> >
> > 5) para 2, bullets 1 & 2
> > The term "strategy" didn't seem appropriate. In bullet 1,
> > consider "convention" instead. In bullet 2, "strategy" also
> > indicated more policy-making than is required, when it is
> > just identifying default values or responses.
> > Consider something more along the lines of "planning
> > languages to be returned, when languages are requested that
> > you don't support".
> >
> > 6) para 3
> > delete the word "unfortunately". It's ambiguous as to what is
> > unfortunate, and it is not needed.
> 
> Done.
> 
> >
> > 7) para 4
> > Split the second sentence into 2 sentences.
> > The para should also say something to the effect: "This faq
> > describes only the Multiviews approach."
> 
> Split using ;
> 
> >
> > 8) The heading "One possible approach" should be "Using
> > Multiviews to configure Language Negotiation", "The Multviews
> > Approach", or some such.
> 
> Removed.
> 
> >
> > 9) We suggest the default be something other than english.
> 
> See below.
> 
> >
> > 10) Section on File Naming
> > Should other file types be considered besides html? (xml, css, jpg...)
> 
> Referred to later.  Want to keep this simple.
> 
> >
> > 11) para 3,
> > 1st sentence refers to accessing the files when not on an
> > apache server.
> > Perhaps it should say when accessed directly, or when not
> > accessing thru the network to the server. After all, even
> > while being served, they can be accessed directly locally.
> > Similarly, the next phrase should refer to "accessing the
> > resource via the apache server."
> >
> > 12) Just curious, given the example, the multiviews must
> > always refer to html. If there were 2 files example.jpg and
> > example.html, the href without the extension would return the html?
> 
> See below.
> 
> >
> > 13) reference to rfc 3066 should also be in the links section.
> 
> Done.  The references hadn't been developped yet.
> 
> >
> > 14) More generally, there should be many more links inline in
> > the text, so people can reference immediately if they choose,
> > and not have to look to the links section to see if there is
> > a link there.
> 
> I hadn't worked out all the links yet.  I added some.
> 
> >
> > 15) The name of the file .htaccess is not optional is it? If
> > it is mandatory, the sentence should not say "typically be called".
> 
> It is optional.  See below.
> 
> >
> > 16) Not discussed in the meeting, but I think the sentence
> > recommending a default of English should be deleted. The
> > widespread nature of english is irrelevant unless your page
> > is directed for the public at large. The choice of default
> > should reflect the makeup of your target audience and might
> > very well be some other language. And english can't be a
> > default if you haven't translated to english.
> 
> It's just an example.  But typically English is a good choice for a lingua
> franca.
> 
> >
> > 17) specifying the default files 2.030 and above
> > ForceLanguagePriority does not specify the default, the
> > prioritization of languages does. FLP suggests the
> > methodology. Also, LanguagePriority is not specifying a
> > particular file, but the language. The first sentence should
> > be rewritten.
> 
> Done.  Both are needed.
> 
> >
> > 18) Some text should explain the logic behind the example, as
> > opposed to  stating the result.
> > FLP allows a fallback method to be used, and the Lang.Pri.
> > declares the ordering of possible choices. If a Spanish page
> > doesnt exist, and if an English page does exist, then it will
> > be served. If not, then a French page will be served. and so forth.
> > (This is what we speculated the behavior to be. It needs
> > confirmation.)
> 
> I'm trying not to make this the length of a chapter in a book.  I added text
> to say follow the links for the detail.
> 
> >
> > 19) section on default files in 1.3.4 and above
> > The heading should instead refer to versions 2.0.30 and
> > below, or if we think there might be someone still using a
> > version less than 1.3.4, than "versions 1.3.4 to 2.0.30".
> 
> Done.
> 
> >
> > 20) aha! I just read the BTW. Suggest mentioning that files
> > other than html can be used, within the answer. With a
> > section name like "BTW", idiots like me may not read it, as
> > it sounds extraneous. However, the point about extensions is
> > fundamental.
> 
> Done.
> 
> >
> > 21) Background
> > First sentence would be slightly less ambiguous if it added
> > "user's" to " language preferences". Also, perhaps use active
> > voice to improve readability. e.g.
> >
> > User agents provide information about the user's language
> > preferences in the HTTP Accept-Language header of the request
> > to a server for a document.
> > (Also provide a link to accept-language header)
> 
> Changed.
> 
> >
> > 22) Localisation, practise and other terms use British spelllings.
> > We were hoping Santa brought you an American spell-checker! ;-)
> 
> He didn't need to.  I have one, but hadn't yet used it.  Btw, there was ONLY
> those two errors, and the spell-checker doesn't pick up on the second! ;)
> 
> >
> > 23) There is a question of how to use the recommendation of .pl-pl.
> > Is it:
> >       addlanguage             pl .pl-pl
> >       LanguagePriority        en pl fr
> >
> > i.e. pl-pl is the extension, it gets assigned a language
> > code, and then LanguagePriority uses language codes?
> >
> > Perhaps use polish throughout to make it clear.
> >
> > 24) The link for rfc 1766 is wrong.
> 
> It needed replacing anyway.
> 
> >
> > 25) Does the order of the statements in the .htaccess file
> > make a difference? if so what is the preferred ordering? If
> > not, state so.
> 
> No.
> 
> >
> > 26) Does the .htaccess only apply to the current directory,
> > or are subdirectories also affected? (I think subdirs are
> > affected, unless they have their own .htaccess).
> 
> Subdirectories are affected.
> 
> >
> >
> > 27) The group felt that with the changes we recommended the
> > faq could/should be published.
> >
> >
> 
> Thankyou.

-- 
-------------------------------------------------------------
Tex Texin   cell: +1 781 789 1898   mailto:Tex@XenCraft.com
Xen Master                          http://www.i18nGuy.com
                         
XenCraft		            http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------

Received on Monday, 12 January 2004 15:58:45 UTC