-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
document use with alternatives #13
Labels
Comments
I will add the section to the readme |
eigengrau
added a commit
to eigengrau/lektor-atom
that referenced
this issue
Aug 8, 2018
While lektor-atom currently supports creating feed variants by relying on specially-crafted item query expressions, this is only useful for item model fields that contain natural language strings. When creating feeds based on structured data, this is not helpful, since field values are identical across two alts. E.g., when we would like to publish a feed based on PDF attachments that have a `volume_number` set, we are currently unable to have the English feed display item titles as »Volume 1« in the English feed resp. »Ausgabe 1« in the German alternative. This commit adds support for such use-cases by adding two new mechanisms: 1. Instead of supplying field names to map records to Atom entries, the user supplies a Jinja template. These expressions are evaluated with `this` bound to the blog resp. the item record. 2. For a feed named `feed`, configuration values are first looked-up in the config file section `[feed.ALT]`, where `ALT` is the alternative currently being generated. This allows settings defaults in `[feed]`, and overriding only those settings that are locale-specific by adding them to `[feed.ALT]`. As a side-effect, this also benefits users that don’t use alternatives, since it enables them to compose item titles, bodies, etc. using multiple fields at the same time. Fixes lektor#3, lektor#13.
eigengrau
added a commit
to eigengrau/lektor-atom
that referenced
this issue
Aug 9, 2018
While lektor-atom currently supports creating feed variants by relying on specially-crafted item query expressions, this is only useful for item model fields that contain natural language strings. When creating feeds based on structured data, this is not helpful, since field values are identical across two alts. E.g., when we would like to publish a feed based on PDF attachments that have a `volume_number` set, we are currently unable to have the English feed display item titles as »Volume 1« in the English feed resp. »Ausgabe 1« in the German alternative. This commit adds support for such use-cases by adding two new mechanisms: 1. Instead of supplying field names to map records to Atom entries, the user supplies a Jinja template. These expressions are evaluated with `this` bound to the blog resp. the item record. 2. For a feed named `feed`, configuration values are first looked-up in the config file section `[feed.ALT]`, where `ALT` is the alternative currently being generated. This allows settings defaults in `[feed]`, and overriding only those settings that are locale-specific by adding them to `[feed.ALT]`. As a side-effect, this also benefits users that don’t use alternatives, since it enables them to compose item titles, bodies, etc. using multiple fields at the same time. Fixes lektor#3, lektor#13.
eigengrau
added a commit
to eigengrau/lektor-atom
that referenced
this issue
Aug 9, 2018
While lektor-atom currently supports creating feed variants by relying on specially-crafted item query expressions, this is only useful for item model fields that contain natural language strings. When creating feeds based on structured data, this is not helpful, since field values are identical across two alts. E.g., when we would like to publish a feed based on PDF attachments that have a `volume_number` set, we are currently unable to have the English feed display item titles as »Volume 1« in the English feed resp. »Ausgabe 1« in the German alternative. This commit adds support for such use-cases by adding two new mechanisms: 1. Instead of supplying field names to map records to Atom entries, the user supplies a Jinja template. These expressions are evaluated with `this` bound to the blog resp. the item record. 2. For a feed named `feed`, configuration values are first looked-up in the config file section `[feed.ALT]`, where `ALT` is the alternative currently being generated. This allows settings defaults in `[feed]`, and overriding only those settings that are locale-specific by adding them to `[feed.ALT]`. As a side-effect, this also benefits users that don’t use alternatives, since it enables them to compose item titles, bodies, etc. using multiple fields at the same time. Fixes lektor#3, lektor#13.
eigengrau
added a commit
to eigengrau/lektor-atom
that referenced
this issue
Aug 9, 2018
While lektor-atom currently supports creating feed variants by relying on specially-crafted item query expressions, this is only useful for item model fields that contain natural language strings. When creating feeds based on structured data, this is not helpful, since field values are identical across two alts. E.g., when we would like to publish a feed based on PDF attachments that have a `volume_number` set, we are currently unable to have the English feed display item titles as »Volume 1« in the English feed resp. »Ausgabe 1« in the German alternative. This commit adds support for such use-cases by adding two new mechanisms: 1. Instead of supplying field names to map records to Atom entries, the user supplies a Jinja template. These expressions are evaluated with `this` bound to the blog resp. the item record. 2. For a feed named `feed`, configuration values are first looked-up in the config file section `[feed.ALT]`, where `ALT` is the alternative currently being generated. This allows settings defaults in `[feed]`, and overriding only those settings that are locale-specific by adding them to `[feed.ALT]`. As a side-effect, this also benefits users that don’t use alternatives, since it enables them to compose item titles, bodies, etc. using multiple fields at the same time. Fixes lektor#3, lektor#13.
eigengrau
added a commit
to eigengrau/lektor-atom
that referenced
this issue
Aug 9, 2018
While lektor-atom currently supports creating feed variants by relying on specially-crafted item query expressions, this is only useful for item model fields that contain natural language strings. When creating feeds based on structured data, this is not helpful, since field values are identical across two alts. E.g., when we would like to publish a feed based on PDF attachments that have a `volume_number` set, we are currently unable to have the English feed display item titles as »Volume 1« in the English feed resp. »Ausgabe 1« in the German alternative. This commit adds support for such use-cases by adding two new mechanisms: 1. Instead of supplying field names to map records to Atom entries, the user supplies a Jinja template. These expressions are evaluated with `this` bound to the blog resp. the item record. 2. For a feed named `feed`, configuration values are first looked-up in the config file section `[feed.ALT]`, where `ALT` is the alternative currently being generated. This allows settings defaults in `[feed]`, and overriding only those settings that are locale-specific by adding them to `[feed.ALT]`. As a side-effect, this also benefits users that don’t use alternatives, since it enables them to compose item titles, bodies, etc. using multiple fields at the same time. Fixes lektor#3, lektor#13.
Did this ever get implemented in master? I see there's eigengrau@ad6502f in a fork but it seems like lektor-atom still doesn't support alternatives... |
Aha! So the PR is #16. That looks stale... |
jcharaoui
pushed a commit
to jcharaoui/lektor-atom
that referenced
this issue
Oct 20, 2021
While lektor-atom currently supports creating feed variants by relying on specially-crafted item query expressions, this is only useful for item model fields that contain natural language strings. When creating feeds based on structured data, this is not helpful, since field values are identical across two alts. E.g., when we would like to publish a feed based on PDF attachments that have a `volume_number` set, we are currently unable to have the English feed display item titles as »Volume 1« in the English feed resp. »Ausgabe 1« in the German alternative. This commit adds support for such use-cases by adding two new mechanisms: 1. Instead of supplying field names to map records to Atom entries, the user supplies a Jinja template. These expressions are evaluated with `this` bound to the blog resp. the item record. 2. For a feed named `feed`, configuration values are first looked-up in the config file section `[feed.ALT]`, where `ALT` is the alternative currently being generated. This allows settings defaults in `[feed]`, and overriding only those settings that are locale-specific by adding them to `[feed.ALT]`. As a side-effect, this also benefits users that don’t use alternatives, since it enables them to compose item titles, bodies, etc. using multiple fields at the same time. Fixes lektor#3, lektor#13.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We should document how to use this plugin with alternatives.
See as an example
https://github.com/pybee/pybee.github.io/blob/lektor/configs/atom.ini
https://github.com/pybee/pybee.github.io/blob/lektor/templates/blog.html#L8
The text was updated successfully, but these errors were encountered: