AltoTrail now saves favorites in a more durable way, so they are no longer tied only to the current session.
AltoTrail has now improved how saved favorites are stored.
Previously, favorites were tied to the current session. That meant they could disappear when an older session was cleaned up. Favorites are now moving to a user-based storage model instead, so they can survive across sessions for the same user.
This is a small change in the interface, but an important improvement in behavior. A favorite is usually a signal that something should be kept, not just hidden for the moment.
At the same time, hidden listings still remain session-based. That is intentional. Hiding something often means “do not show this right now,” while a favorite means “keep this for later.”
This makes the behavior easier to understand and gives AltoTrail a calmer and more reliable saved-list model without adding account complexity yet.
Current focus:
Verify the new behavior outside DEV and keep the model simple while hidden listings remain session-based.
FAQ and Project Updates now keep users on the same page when switching between English and Swedish.
AltoTrail has now improved language switching for the public document pages.
FAQ and Project Updates now have their own English and Swedish routes. This means the language switcher keeps users on the same kind of page instead of sending them back to the start page.
If no language is selected, AltoTrail now starts from the user’s own language settings. That makes the document pages feel more natural from the start.
This is a small change, but an important one. Language switching should feel predictable and calm.
There is one clear exception for now. The legal pages remain English-only. Because of that, the normal language switcher is hidden there instead of pretending that a Swedish legal page already exists.
That keeps the behavior honest and easier to understand.
Current focus:
Keep the document routes simple and consistent, and review later whether legal pages should also get their own language routes.
AltoTrail Explorer now shows a simpler tree and gives clearer feedback while loading job availability.
Recent work has focused on making the Explorer tree easier to read.
Some labels in the tree previously showed counts that represented structure, such as how many countries, regions, or nearby labels were available. Explorer now puts more emphasis on the numbers that matter most to a job seeker: actual job availability.
Explorer also now gives clearer visual feedback when new parts of the tree are loading. This makes it easier to understand that the system is working, especially when live availability takes a moment to appear.
This is a small improvement, but an important one. Explorer should feel calm and understandable, not technical or ambiguous.
Current focus:
Keep improving Explorer step by step so job availability is easier to understand without making the interface more technical.
AltoTrail has made the multilingual route structure clearer across the main public pages.
Recent work has focused on making the public route setup more consistent across the root page, Assistant, and Explorer.
The main idea is unchanged. Language-specific routes are still the primary public pages, while the original non-prefixed routes remain in place as more neutral entry points.
This matters because AltoTrail is gradually becoming a clearer public product. The route structure is now easier to understand and more consistent across the main page families.
This was not a new feature in the usual sense. It was a cleanup and clarification step that makes the existing multilingual setup feel more intentional.
Current focus:
Follow how the updated routes behave in Search Console and keep using the same structure for future public pages.
AltoTrail added a first working compare workspace in AltoTrail Explorer, making it possible to inspect URI-based and term-based EURES results side by side.
Recent AltoTrail work has turned earlier EURES verification into a working implementation inside Explorer.
The new slice adds a server-side compare path and a first report-style workspace in the right panel. This makes it possible to inspect URI-based occupation retrieval and term-based title retrieval in a more direct and visual way.
This matters because the two search modes do not behave the same. They can produce different totals, different country distributions, and different region patterns. Instead of treating those differences as abstract theory, AltoTrail can now study them in a working tool.
The first version is intentionally technical. It focuses on summary, compare, and raw report views so the retrieval model can be understood before more user-facing views such as maps, listing presentations, or broader search workflows are built.
Current focus:
Use the new compare workspace to study how concept-based and title-based search differ before deciding how future explorer behavior should work.
AltoTrail is preparing a new public updates page built from English markdown, with translated cached versions for other languages.
AltoTrail is moving toward a more transparent public product. The goal is to make it easier to follow what is being built without asking visitors to read internal architecture documents.
This work is not about creating a blog or a news system. It is about adding a calm and readable timeline that explains important development steps in plain language.
The first version is intentionally simple: one long scrollable page with the newest updates first.
Current focus:
Define the content format, parsing model, translation flow, and cache structure.
Recent verification work has focused on how EURES behaves in practice and what that means for reliable role retrieval.
Recent AltoTrail work has focused on verifying how EURES behaves at the API level and where the real behavior differs from earlier expectations.
This matters because AltoTrail depends on external job sources, and a trustworthy product needs to reflect how those sources actually behave. Verified observations are more useful than assumptions when the goal is stable job search behavior.
The result is a more careful and reality-based approach to query design and provider handling.
Current focus:
Keep retrieval behavior explicit, inspectable, and grounded in verified observations rather than assumptions.
AltoTrail Explorer has moved from local prototype status toward a visible AltoTrail tool with published routes and shared navigation support.
AltoTrail Explorer is no longer only an internal prototype. It now has a clearer place in AltoTrail’s public product.
This step matters because occupation exploration is becoming a visible part of the product rather than a separate experiment. It also helps AltoTrail grow from a single assistant into a broader set of tools.
The work has been kept deliberately conservative. Publication and navigation improvements were separated from deeper runtime and domain-data questions.
Current focus:
Continue improving the current technical navigator surface without mixing publication work with deeper runtime changes.
Explorer now has a first live country-count slice and a clearer split between exploration and results behavior.
Explorer can now show live country-count discovery for occupation nodes. This creates a more concrete link between occupation exploration and real job availability.
The main purpose of this step was clarity. AltoTrail now keeps a more explicit split between inspecting an occupation and opening a results-focused workspace.
That makes Explorer easier to understand and prepares it for future growth without expanding the core runtime contract too early.
Current focus:
Extend country-group behavior under alternative occupation labels.
The Explorer frontend has been split into clearer modules and prepared for future publication-aware and multilingual work.
As Explorer grew, it became important to separate responsibilities in the frontend instead of letting a few files become too large.
This step was mainly about maintainability. A cleaner structure makes later work safer, easier to test, and easier to understand.
At the same time, AltoTrail also prepared the ground for future UI translation work in Explorer without mixing that with ESCO domain-data translation.
Current focus:
Keep the frontend structure small and understandable while new features are added.
AltoTrail introduced a stronger multilingual publication model for root and assistant pages, with language-specific HTML served directly by the web server.
This was an important product and SEO step. Instead of relying only on client-side updates, AltoTrail now serves language-aware publication HTML directly for published routes.
That improves clarity for users, gives search engines a better public result, and reduces the gap between visible content and route identity.
The key idea was to keep published content deterministic and repo-controlled, while leaving runtime UI translation as a secondary layer rather than the source of truth for public pages.
Current focus:
Extend the same clean publication model to more public-facing content surfaces.
AltoTrail introduced a multilingual FAQ page with English canonical content, server-side rendering, and cached translated versions.
The FAQ page was created to answer common product questions without making the Assistant interface heavier or more crowded.
This also became an important architectural milestone. AltoTrail now has a validated pattern for content translation: English source content, model-routed translation, structured cache storage, and safe fallback to English.
That pattern is now useful beyond FAQ and is directly relevant to the new Project Updates page.
Current focus:
Reuse the same translation and cache principles for other structured public content.
AltoTrail established its first staging-capable VPS deployment model with Git-based updates and documented service structure.
This step moved AltoTrail further away from a local lab-only setup and closer to a real deployed product.
The main purpose was not feature growth, but operational clarity. A product becomes easier to trust when deployment, restart behavior, and service layout are explicit and repeatable.
That infrastructure work created a stronger foundation for testing public-facing changes in a realistic environment.
Current focus:
Keep deployment reproducible and close to production behavior.
AltoTrail introduced a more stable canonical architecture for listings and geographic data.
This was one of the more important structural steps in AltoTrail. The purpose was to reduce duplication, improve identity stability, and create a cleaner foundation for listings, location data, and later map-related behavior.
Even though this work is deeply architectural, the reason behind it is simple: users should not lose coherence just because data is processed through repeated runs.
The long-term effect is a more stable product foundation with less hidden duplication and clearer responsibility boundaries.
Current focus:
Preserve stable identity and reusable data without changing the user-facing workflow more than necessary.
AltoTrail introduced baseline runtime guardrails to make the product safer and more stable without changing pipeline semantics.
As AltoTrail moved closer to a public-facing product, it became necessary to add lightweight runtime guardrails around requests, concurrency, and generation behavior.
This step was about practical safety rather than feature work. The goal was to reduce avoidable misuse, control cost exposure, and make system behavior more predictable.
The important design choice was to do this without changing the meaning of the pipeline itself.
Current focus:
Keep the product operationally safe while preserving deterministic behavior.
The project transitioned from an internal lab-style surface into a clearer public product identity under the AltoTrail name.
This was a presentation-layer shift, but an important one. A product needs a clear identity before it can feel trustworthy and intentional.
The purpose of this step was to move away from internal or experimental language and toward a clearer public product.
That change helped connect architecture work, UI refinement, and product direction into a more coherent whole.
Current focus:
Continue turning technical progress into a more coherent and understandable product.