Sort the complete result before deciding what belongs on each page

A page can look alphabetically correct while the directory as a whole is wrong. This happens when the server chooses a group of records under one ordering and the browser rearranges only that group under another. The browser cannot place a missing record on the page because it never received it.

For an Estonian interface, language adaptation therefore includes the behaviour used to find information, not just the headings around it. The ordering must be consistent at the point where page membership is decided. The following fictional investigation shows how to establish that boundary without changing customer names or treating a visual sort as proof of the whole result.

Establish the expected directory

The example uses six invented display names. “Demo” is part of each test value; none represents a customer. The directory has three records per page and a fixed dataset during the check. All six records meet the same filter and permission rules.

The selected Estonian collation puts Õ before Ä in this sequence. Unicode’s Estonian collation chart documents the relevant language ordering. The chart is explanatory; an implementation should use its supported locale-aware collation facilities rather than scrape the chart into a homemade alphabet.

The acceptance expectation is exact: page one contains C-11, C-12 and C-13, in that order; page two contains C-14, C-15 and C-16. The total is six, with no repeated or missing record. That expectation is stronger than “each page is sorted.”

Inspect the point where the page is selected

In the fictional application, the server uses a binary ordering of the display-name values and then takes three rows. Its first response contains C-11, C-12 and C-14. Its second contains C-13, C-15 and C-16. The browser applies the Estonian comparator separately to each response.

The resulting pages look plausible. Page one shows Tamm, Vaher and Ääre; page two shows Õun, Öö and Ülem. No row is duplicated, the total is correct and every name is spelled correctly. Yet the first page is missing Õun, which belongs before Ääre under the selected ordering.

Inspecting the response establishes that the wrong membership already exists before rendering. The filter has not excluded C-13: the second response contains it. The stored name is intact. The browser’s comparator also gives the expected sequence when supplied with all six records. Those controls isolate the failure to selecting the page under an incompatible ordering.

Changing the heading, stripping accents or adjusting the browser’s sort would not address that cause. Fetching the entire production directory merely to sort it in the browser would also change the performance and access assumptions; it should not be adopted as an incidental content fix.

Correct the selection boundary

The fictional correction makes the supported server query apply the agreed Estonian ordering to the filtered result before pagination. The display values remain unchanged. The query also uses the stable record identifier to break ties between names that compare equally under the selected settings.

That final tie-break matters. Two separate records can have the same display name, and their relative order should not depend on an incidental database execution plan. PostgreSQL’s LIMIT and OFFSET documentation explains the need for a predictable, unique ordering when selecting portions of a result. Other data systems need an equivalent review of their own supported query behaviour.

The team records the chosen locale, comparison settings and secondary identifier. It does not assume that a database collation and a browser comparator with similar labels are necessarily interchangeable in every detail. The tested values and the deployed configuration form part of the acceptance evidence.

Record the completed checks

After the correction, the fictional response for page one is C-11, C-12, C-13; page two is C-14, C-15, C-16. The browser presents those records in the same order. Concatenating the two responses produces the expected six-record sequence, and the total remains six.

A separate tie check uses two records named “Tamm Demo”, with stable IDs C-21 and C-22 and a page size of one. The agreed identifier order consistently places C-21 on the first page and C-22 on the second. The check repeats against the unchanged dataset; it does not claim to solve records moving during concurrent edits.

The existing English directory is a separate control. Its six-name order remains Ääre, Öö, Õun, Tamm, Ülem, Vaher under the English comparison used in the fixture. The correction does not silently impose Estonian ordering on that view. Both routes retain their own language labels and the same underlying record identities.

Carry the decision into future changes

Document what happens when users change a filter, language or sort direction. Page selection should follow the chosen ordering, and an obsolete cursor or page number may need to be reset under the application’s supported design. If records can change while someone browses, separately decide whether snapshot consistency, cursor pagination or another approach is required. The fixed-dataset test does not establish those behaviours.

Include names that compare equally and values with relevant language characters in later regression checks. Do not alter legal or preferred names to make a deficient sort appear consistent. The content and publishing service can help define language ownership, while business application work can address the record behaviour behind the interface.

For a project brief, bring the expected complete sequence, the actual page responses and the selected filters. That evidence lets the investigation answer a precise question: where did the correct record leave the correct page?