How featured articles and chronological order coexist

“Latest” and “featured” both seem to tell readers which article to read first. They answer different questions.

Sorting by latest answers: which articles most recently met the requirements for publication? The featured flag answers: which articles does the editor want to draw attention to at the entrance to the list? If both are collapsed into one sorting field, each new publication will push the editor’s chosen entry points farther down the list. If time is ignored altogether, readers cannot tell how recent the content is.

The implementation separates those responsibilities: the public collection is first sorted by publication time and stable ID. Every valid list page then shows featured articles in a separate featured block, while ordinary articles are paginated on their own.

Publication dates determine which articles enter the collection

The public notes query checks eligibility before layout:

• draft must be false.
• The article must have a publishedAt value.
• The publication date must not be later than today’s date in Taipei.
• When a language is requested, locale must match.

Once articles qualify, the collection is sorted by publishedAt, newest first. If publication timestamps match to the second, stableId provides a deterministic tie-break. This layer only decides which articles are eligible for publication and how to calculate the latest order. Marking an article as featured does not change its date.

So featured is neither a publication requirement nor another kind of date. A draft cannot enter the public website early by setting featured: true, and a future-dated article cannot bypass the publication conditions by being featured.

The list page handles the featured block afterward

Only after the notes list receives the sorted public collection does it split the articles into two groups:

Articles eligible for publication
  ├── featured articles → Featured block on every valid page
  └── Non-featured articles → Ordinary article list and pagination

The featured block appears on every valid page. The ordinary list excludes featured articles, so the same article does not appear again in the regular list. Pagination for ordinary articles is calculated using only the non-featured collection.

This lets readers find featured articles on every page without disrupting the ordinary list’s counts or pagination. Page 2 and later pages repeat the same featured collection, but those articles do not occupy regular-list slots or change its page count.

If there are only featured articles and no ordinary articles, the list still has public content. The ordinary block does not duplicate cards just to fill the layout. An empty state appears only when that language has no articles eligible for publication at all.

Featured does not mean pinned on the homepage

The homepage takes up to three of the latest public articles in the selected language. It uses the publication-date sort result without separately moving featured articles to the front.

The same metadata can therefore have different responsibilities on different pages:

• The Notes list uses it to create a featured block.
• The homepage uses the latest order to show recent articles.
• Article pages and the sitemap only care whether an article qualifies for public output.

This is a difference in page responsibilities, not inconsistent data. The featured flag is an editorial signal for the list’s presentation, not a command to pin an article across the entire website.

The featured block has no manual ordering

The featured collection retains the public query’s publication-time and stableId ordering. The metadata is only a boolean; there is no separate featuredOrder, weight, or fixed pinning time.

When two articles are featured, the system knows that both belong in the featured block. Their frontmatter cannot express that one must always appear before the other. If editorial ordering is needed later, it will require a clear data contract and validation. File order or build-time reading order cannot serve as the sorting rule.

This limitation makes the behavior easier to understand:

• The publication date determines chronological order.
• featured determines whether an article enters the featured block.
• stableId provides the final, deterministic tie-break only when publication timestamps match.

None of these fields stands in for the others.

Why featured articles do not go back into the ordinary sort

Moving featured articles directly to the top of the ordinary list would create several problems:

• Rules for the latest articles and editorial recommendations would be mixed together, making the list order hard to understand.
• Featured articles would occupy ordinary pagination slots, potentially pushing some ordinary articles onto the next page.
• Removing the featured flag would suddenly change an article’s relative position, without making it clear whether time or an editorial flag caused the change.
• If featured states differed across language versions, their list orders could differ in ways that are hard to explain.

The separate block is not an attempt to make the homepage more complicated. It keeps recommendation signals and time signals readable. A page can first introduce a few articles the editor wants to draw attention to, then use the ordinary list to present the full chronological sequence.

The use of featured needs limits too

featured suits articles worth introducing at the entrance to the list: articles that represent the website’s direction, help new readers understand its scope, or remain worth reading first even when they are no longer the latest.

It should not be used as any of the following:

• An automatic score of article quality.
• A guarantee of search rankings or traffic.
• A way to expose a draft that has no publication date.
• A field set arbitrarily just to give the layout a large card.
• Another ordinary list created by marking every article as featured.

If too many articles are featured, the block no longer reads as a selection. At that point, the first question should be whether the featured block is still needed, rather than simply continuing to set more boolean flags.

Decide editorial responsibility across language versions

featured belongs to each language version’s own article metadata. If the Traditional Chinese, English, and Japanese versions sharing a stableId have different featured states, they can produce different recommendations in their language-specific lists.

That is not necessarily an error, but it needs to follow a deliberate rule. Possible policies include:

• Edit featured selections independently for each language, respecting the entry points its readers need.
• Share the featured decision across the same stableId, requiring translations to be updated together.
• Feature articles only in languages with published content, without reserving flags for translations that do not exist.

The code handles each article’s own featured value; it does not validate featured consistency across languages for the same stableId. A shared featured policy for all three languages would need a data contract first, followed by changes to the list and tests.

Check the two ordering responsibilities separately

When adding an article or changing its featured state, check the following in order:

1. Does the article first meet the requirements for publication?
2. Without the featured flag, does the publication-time and stableId ordering remain as expected?
3. After the article is featured, does it appear in the featured block on every valid page?
4. Does the ordinary list exclude featured articles, and are its pagination counts still correct?
5. Does the homepage still show up to three of the latest articles, rather than accidentally switching to featured ordering?
6. Does the sitemap reflect only public list and article routes, without treating metadata as a new URL?

These checks can confirm that the data fields are used correctly. They cannot establish whether the featured articles genuinely help readers. Recommendations still depend on the editorial judgment of the editor and site owner.

Featured is an editorial concept; time is a publication concept. Keeping their responsibilities separate means the list does not need one vague “importance” field to stand in for recency, recommendations, and public eligibility at once.

Scope of this record

This article draws on the notes schema, public sorting function, list component, pagination routes, homepage query, and sitemap implementation. It records the engineering behavior of featured and chronological ordering described in the original note of October 2, 2026. It does not claim that featuring an article necessarily increases readership or present consistency across language versions as an already implemented feature.