I prefer '.xml' to '.atom' for Atom feeds.

We can’t really change that, and our current Atom implementation is good enough (we want to use feedgenerator for RSS only)

OK. I have no problem. I will withdraw this PR.

Wait, no. We could take this from here and make the necessary changes.

I know that .atom file extension recommended on RFC 4287 https://www.ietf.org/rfc/rfc4287.txt.
But Google says:

Section 2: Important Checklist
Before you submit your feed, we highly recommend running through the following list to help ensure your file is properly formatted:

1. Your filename must end with the .xml extension.

at https://support.google.com/merchants/answer/160593?hl=en
So I believe .xml file extension is in advantageous for SEO.

That’s Google Shopping, not Google Search.

Yes. I know. It's my preference.
But I will resubmit to output Atom feeds with .atom extension.

Using .atom will get you the correct Content-Type header from most servers without configuring anything on the server. As a static generator, “without configuring anything on the server” is important. As for “SEO reasons” and client compatibility, the file extension does not matter in the least; only Content-Type – the .atom file extension gets us the correct Content-Type.

First attempt at building:

TaskError - taskid:render_indexes:en:output/index-atom.xml
PythonAction Error
Traceback (most recent call last):
  File "/usr/lib/python3.4/site-packages/doit/action.py", line 383, in execute
    returned_value = self.py_callable(*self.args, **kwargs)
  File "/usr/lib/python3.4/site-packages/nikola/feedutil.py", line 192, in gen_feed_generator
    fg.title(title=title, type=None, cdata=False)
TypeError: title() got an unexpected keyword argument 'type'

I must be using the wrong feedgen here, because almost none of the features you’re using exist in the feedgen documentation nor do they exist in the code.

👎 You’re stripping away much of the support for RFC 5005. 👎 link rel=next-archive, link rel=prev-archive, link rel=current, and the archive element on stale feeds are all missing. link rel=last have been added but should be removed (as we continuously update with new feeds so there is no last feed).

I can’t get this to run at the moment, but from looking at the code, the output will be quite different what Nikola produces today.

I implement 3. Paged Feeds (rel=next|previous|first|last), not 4. Archived Feeds (rel=prev-archive|next-archive|current) on RFC5005.
I think that Paged Feeds is more appropriate for Nikola.

I rewote this PR and test it myself.
Original feedgenerator doesn't have a support of things with RFC5005.
Original feedgenerator author don't react to my PR, so shoud I rename my custom feedgenerator and put to PyPI?

(Having email trouble so didn’t see your reply earlier.) Nikola has archives and the archives have feeds (extremely well suited as sitemaps). The archive feed extension is thus very much suited for Nikola.

Sorry for confusing you.
This second PR have a support of 4. Archived Feeds already and my custom feedgenerator have a support of RFC5005.

3.  Paged Feeds
...
   Paged feeds are lossy; that is, it is not possible to guarantee that
   clients will be able to reconstruct the contents of the logical feed
   at a particular time.  Entries may be added or changed as the pages
   of the feed are accessed, without the client becoming aware of them.

   Therefore, clients SHOULD NOT present paged feeds as coherent or
   complete, or make assumptions to that effect.

rel=last is no problem.

rel=(first|last|prev|next) are for 3. Paged Feeds in RFC5005.
rel=(current|prev-archive|next-archive) are for 4. Archived Feeds in RFC5005.

@masayuko Sorry about letting your PRs rot ffor so long. I will take a good look at them tomorrow so we can move them forward and merge your work. Thanks for the patience and the effort!

Unfortunately, this PR has lingered for a very long time, and is probably very outdated (right now, there are 33 merge conflicts), so getting it working with the modern version of Nikola would be a bit of a hassle. I will close this PR and will try to spend some time on re-implementing this feature, partially from scratch, partially using code from this PR.