~dmbaturin/soupault

2 2

i18n and index.views on normal pages?

Details
Message ID
<c1f8c60954793b9ae113754212b071d5@raphinou.com>
DKIM signature
missing
Download raw message
Hi,

I'm a new soupault user, and I really enjoy it. It's exactly the tool I 
need. It's great I can just use an html template without having to first 
convert it to a special format!

After having finished my first website with soupault, I have 2 
questions:
- if I understand correctly: why are index views limited to index.* 
pages? I display a tag cloud on the blog's index page, and would have 
liked to also display it in the margin of blog posts, but it seems the 
limitation of index usage prevents this. Or is there a way I'm not aware 
of?
- An example of a multi-language website managed with soupault would be 
great. It's not an immediate need, but this is probably something I'll 
need in the future. It's not yet clear to me what the best approach 
would be.

Thanks for this great tool!
Details
Message ID
<b0d27ed0-c630-4c10-b334-15556412c5c4@baturin.org>
In-Reply-To
<c1f8c60954793b9ae113754212b071d5@raphinou.com> (view parent)
DKIM signature
missing
Download raw message
Hey,

 >why are index views limited to index.* pages?

The practical answer is that you can make index data available to all 
pages with `index.index_first = true`
(see 
https://soupault.app/reference-manual/#making-index-data-available-to-every-page)

Now a longer answer as to why it's not the default... the reason why 
index data is only available to index pages by default
is that I wanted soupault to be able to handle websites that are larger 
than the available amount of memory.

CMSes solve the problem by storing taxonomies and other metadata in a 
database and querying it dynamically.
If all metadata is stored inside pages rather than in a persistent 
storage with fast queries, you need some compromises.
Jekyll et al. choose to mimic a CMS by loading all pages into memory at 
once and extracting metadata from their front matter,
so that templates have access to variables like `site.tags`.
But that also means that if you have a website with lots of pages (say, 
a static copy of Wikipedia), trying to process it
on a machine with a modest amount of memory (like a CI worker) will 
cause the process to run out of memory and crash.

Soupault builds a list of all pages first, then sends each of them to a 
function that reads the page files from disk,
extracts metadata, then renders the page and saves the result to disk.
The page source and element tree can then be safely garbage collected,
so soupault is technically capable of processing sites of arbitrary size
(as long as there's enough memory for the page list and for processing 
at least one page).
Only when all content pages are processed and all index data is 
extracted, then index pages are rendered.

But it means that a content page is removed from memory before the 
complete index data is available.
This works well for most sites I think, but indeed doesn't work if you 
want a tag cloud or similar.
So if you do, you can add `index.index_first = true` to the config and 
get that, at the cost of higher resource consumption.

The book blueprint uses that to create a ToC sidebar, for example: 
https://github.com/PataphysicalSociety/soupault-blueprints-book

 >An example of a multi-language website managed with soupault would be 
great.

I'm not aware of any examples yet. I have to admit that I'm not a fan of 
multilingual sites and I believe that in most cases
when websites in different languages are actually required and useful, 
it may be better to just make multiple websites.
But I can see how a post-index hook might extract the language from 
"about.en.md" and set a field,
then use it for creating language sections, for example.


On 11/1/23 09:47, rb@raphinou.com wrote:
> Hi,
>
> I'm a new soupault user, and I really enjoy it. It's exactly the tool 
> I need. It's great I can just use an html template without having to 
> first convert it to a special format!
>
> After having finished my first website with soupault, I have 2 questions:
> - if I understand correctly: why are index views limited to index.* 
> pages? I display a tag cloud on the blog's index page, and would have 
> liked to also display it in the margin of blog posts, but it seems the 
> limitation of index usage prevents this. Or is there a way I'm not 
> aware of?
> - An example of a multi-language website managed with soupault would 
> be great. It's not an immediate need, but this is probably something 
> I'll need in the future. It's not yet clear to me what the best 
> approach would be.
>
> Thanks for this great tool!
Raphaël Bauduin <rb@raphinou.com>
Details
Message ID
<a4f4a447-bd4b-4849-8902-1006faa6ab41@raphinou.com>
In-Reply-To
<b0d27ed0-c630-4c10-b334-15556412c5c4@baturin.org> (view parent)
DKIM signature
missing
Download raw message
Thanks for your detailed answer. I had missed the index_first option in 
the documentation.

Regarding multi-languages sites, I would rather not duplicate data 
common between languages. I agree there are some languages that would 
change a lot (eg if a right-to-left language has to be introduced), but 
in most cases I could reuse the templates, css, lots of images, soupault 
plugins and helpers. Duplicating all this in a distinct soupault site to 
make a spanish version in addition to the english version doesn't seem 
to strike the right balance.
Ideally (I think), there would be a general version of the asset (css, 
template, etc) that can be overriden by a language-specific version, and 
each language has its version generated under a sub directory (eg 
build/en, build/es). Just writing this I have some questions arising, so 
I don't think it's a simple thing to achieve.

If I need it and I get something working I'll share it.

Cheers
Reply to thread Export thread (mbox)