I just checked the file using the langcheck script contained in the contrib folder. Please correct the problems reported by the script and I see no problems to include the file:
Validating language file for 'nginx' ...
Failed
ERROR Language file contains trailing empty lines at EOF!
NOTICE Language file contains unescaped tabulator chars (probably for indentation)!
NOTICE Language file contains irregular indentation (other than 4 spaces per indentation level)!
WARNING Language file does not contain a specification of the copyright!
WARNING Language file does not contain a specification of the release version!
WARNING Language file does not contain a specification of the date it was started!
WARNING Language file does not state that it is a language file for GeSHi!
Oh, and please use Linux linebreaks (LF instead of CRLF). Also please include absolute URLs for the linking of keywords.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have created a version of the file that has all the errors found by langcheck.php fixed. As I didn't create the ticket, I am unable to attach it, so I put it on http://pastebin.com/N2dbtzUa
Last edit: Anonymous 2014-03-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've updated the file as requested (I've been waiting to hear back from Cliff Wells before posting it). I had been corresponding with him and was hoping to hear back on whether he approves of my changes, but I understand he's a busy guy.
tbj's comment reminded me that I still needed to post the updated copy.
I spent a lot of time checking wiki and documentation pages along with a look at the source files, but I wouldn't be upset if someone wanted to take it and improve it even further before it was accepted.
I tried to correct the issues I found, but I may have missed something. Feedback is welcome.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For me, langcheck on your file fails with warnings about duplicated keywords. I'm not sure if that is acceptable or not...
Also, do you want to be using the nginx wiki or the official documentation? If you want to switch to using the official documentation, it's as simple as changing all of the documentation URLs to 'http://nginx.org/r/{FNAME}'
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I get the same results. I've checked the warnings and found that the keywords mentioned apply to both groups (modules). Please feel free however to correct any mistakes I made.
Regarding the wiki or documentation pages, Cliff Wells (original author and maintainer of the nginx documentation) mentioned that at some point both will be merged. I know in some cases the wiki pages lacked some directives that the official documentation pages have, but when asked about that Cliff mentioned that the wiki pages _should_ have the same directives documented.
I've also found that the wiki pages include more information and is a little friendlier to newbies (speaking from personal experience). Since the wiki pages usually contain links to the official documentation pages, users would get the best of both worlds.
Lastly, the original file included links to the wiki pages and not the documentation pages, so I just kept the same approach and expanded the relative URLs to absolute URLs as requested.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree with you that it does seem to be best to stick with the wiki documentation for the reasons that you stated.
I think that it would probably be best to clean up the duplicates, otherwise it's non-deterministic which documentation the user is linked to. There are some cases, such as gzip_disable, gzip_http_version, gzip_proxied, and gzip_vary where the documentation on the GzipStaticModule just links to the documentation in the GzipModule. In the cases where it isn't as clear-cut as that, we should probably choose the one that the user is more likely to want. For instance, server_name should probably use the HttpCoreModule documentation rather than the MailCoreModule, since as far as I can tell, far more people use it as an http server than as a mail proxy.
I would be happy to go through and clean them up, but I would be perfectly happy for you to do so as well.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Instead of deleting the keywords, I commented them out so that it was obvious that they had been there and had been removed on purpose.
There was only one real choice that gave me pause was the "server" in context of the "upstream" module vs. the core "server". Unlike the others, most of which do the exactly same thing, these are actually quite different. I went with the core module's "server" due to the fact that (afaik) every config file will have at least one server block, whereas not every config will use the upstream module.
Last edit: Anonymous 2013-09-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
301 Moved Permanently I was recommended this website by my cousin. I am not sure whether this post is written by him as no one else know such detailed about my problem. Youre incredible! Thanks! your article about 301 Moved PermanentlyBest Regards Yoder
<a href="http://www.liveleak.com/c/rhythmporch0" title="Tropical drink">Tropical drink</a>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just checked the file using the langcheck script contained in the contrib folder. Please correct the problems reported by the script and I see no problems to include the file:
Validating language file for 'nginx' ...
Failed
ERROR Language file contains trailing empty lines at EOF!
NOTICE Language file contains unescaped tabulator chars (probably for indentation)!
NOTICE Language file contains irregular indentation (other than 4 spaces per indentation level)!
WARNING Language file does not contain a specification of the copyright!
WARNING Language file does not contain a specification of the release version!
WARNING Language file does not contain a specification of the date it was started!
WARNING Language file does not state that it is a language file for GeSHi!
Oh, and please use Linux linebreaks (LF instead of CRLF). Also please include absolute URLs for the linking of keywords.
View and moderate all "feature-requests Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Feature Requests"
I have created a version of the file that has all the errors found by langcheck.php fixed. As I didn't create the ticket, I am unable to attach it, so I put it on http://pastebin.com/N2dbtzUa
Last edit: Anonymous 2014-03-15
I've updated the file as requested (I've been waiting to hear back from Cliff Wells before posting it). I had been corresponding with him and was hoping to hear back on whether he approves of my changes, but I understand he's a busy guy.
tbj's comment reminded me that I still needed to post the updated copy.
I spent a lot of time checking wiki and documentation pages along with a look at the source files, but I wouldn't be upset if someone wanted to take it and improve it even further before it was accepted.
I tried to correct the issues I found, but I may have missed something. Feedback is welcome.
View and moderate all "feature-requests Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Feature Requests"
For me, langcheck on your file fails with warnings about duplicated keywords. I'm not sure if that is acceptable or not...
Also, do you want to be using the nginx wiki or the official documentation? If you want to switch to using the official documentation, it's as simple as changing all of the documentation URLs to 'http://nginx.org/r/{FNAME}'
tbj,
I get the same results. I've checked the warnings and found that the keywords mentioned apply to both groups (modules). Please feel free however to correct any mistakes I made.
Regarding the wiki or documentation pages, Cliff Wells (original author and maintainer of the nginx documentation) mentioned that at some point both will be merged. I know in some cases the wiki pages lacked some directives that the official documentation pages have, but when asked about that Cliff mentioned that the wiki pages _should_ have the same directives documented.
I've also found that the wiki pages include more information and is a little friendlier to newbies (speaking from personal experience). Since the wiki pages usually contain links to the official documentation pages, users would get the best of both worlds.
Lastly, the original file included links to the wiki pages and not the documentation pages, so I just kept the same approach and expanded the relative URLs to absolute URLs as requested.
View and moderate all "feature-requests Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Feature Requests"
deoren,
I agree with you that it does seem to be best to stick with the wiki documentation for the reasons that you stated.
I think that it would probably be best to clean up the duplicates, otherwise it's non-deterministic which documentation the user is linked to. There are some cases, such as gzip_disable, gzip_http_version, gzip_proxied, and gzip_vary where the documentation on the GzipStaticModule just links to the documentation in the GzipModule. In the cases where it isn't as clear-cut as that, we should probably choose the one that the user is more likely to want. For instance, server_name should probably use the HttpCoreModule documentation rather than the MailCoreModule, since as far as I can tell, far more people use it as an http server than as a mail proxy.
I would be happy to go through and clean them up, but I would be perfectly happy for you to do so as well.
tbj,
Great points.
Like yourself, I'm fine either way, but the earliest I'll get to this will be this weekend as I'm pretty slammed at work this week.
View and moderate all "feature-requests Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Feature Requests"
deoren,
Since you said you were busy, I went ahead and did it.
https://gist.github.com/3517492
Instead of deleting the keywords, I commented them out so that it was obvious that they had been there and had been removed on purpose.
There was only one real choice that gave me pause was the "server" in context of the "upstream" module vs. the core "server". Unlike the others, most of which do the exactly same thing, these are actually quite different. I went with the core module's "server" due to the fact that (afaik) every config file will have at least one server block, whereas not every config will use the upstream module.
Last edit: Anonymous 2013-09-22
tjb,
Thanks. Good idea on commenting them out and giving the reasoning. It should make future maintenance of the file much easier.
Latest copy from https://gist.github.com/3517492
I removed the last copy I uploaded and replaced it with the latest version from https://gist.github.com/3517492
301 Moved Permanently I was recommended this website by my cousin. I am not sure whether this post is written by him as no one else know such detailed about my problem. Youre incredible! Thanks! your article about 301 Moved PermanentlyBest Regards Yoder
<a href="http://www.liveleak.com/c/rhythmporch0" title="Tropical drink">Tropical drink</a>