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

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.

Received on Monday, 12 January 2004 14:39:09 UTC