Labels
Current state of the label system for UI texts and navigation.
Purpose
The label system provides language-dependent UI texts for pages and navigation. It separates interface text from view code, but in the current project it is not a standalone label.service with a static helper like in the old documentation.
Current building blocks
- app/model/label.model.php contains the loading functions getLabel() and getLabels().
- app/core/app.php stores page labels and navigation labels centrally in cApp.
- The actual export source for bulk loading is vw_label_export.
- Depending on the place, views use either cApp::getInstance()->getLabel(...) or the passed $labels array.
Loading in the app
public function setLabels(): void {
$this->labels = getLabels(cSession::getLangID(), cSession::getPageID(), cSession::getCatKey(), true);
}
public function setNavLabels(): void {
$this->navLabels = getLabels(cSession::getLangID(), null, 'nav');
}Current filter logic
getLabels() combines the current language with optional filters for page, group, and global status.
- Page: through pag_IDs with FIND_IN_SET(:pagID, pag_IDs)
- Group: through lky_group LIKE '%-tag-%'
- Global: through lky_is_global
The old documentation with p_{page_key} groups therefore describes more of a target idea than the exact current runtime state.
Query core (simplified)
SELECT DISTINCT lky_key, label_value
FROM vw_label_export
WHERE lan_ID = :lanID
AND (...)
ORDER BY lky_key ASCError behavior
cApp::getLabel() and cApp::getNavLabel() access labels strictly. If a key is missing, an error is logged and the fallback text Label error: <key> is returned. This is intentionally visible and not silent.
Important boundary
Content data such as category names, product names, or article texts do not belong in this label system. It is intended for interface text, not for the actual trading catalog.