lang/bg/gallery.php (1)

45-45: All key renames are structurally correct — minor translation-term inconsistency.

The nine key renames (starred → highlighted, star/unstar → highlight/unhighlight, etc.) are complete and the PHP array syntax is valid.

One optional note: lines 45, 99, 153, 233, and 235 all use the отбелязан- word root, but:

• Line 100 (copy_highlighted_names) uses маркираните (a synonymous but different root).
• Lines 154 and 234 (unhighlight / unhighlight_all) use отметка / отметките (literally "tick/checkmark"), which is slightly different semantically.

If you want full consistency, aligning these to отбелязани/отбележи throughout would read more uniformly. That said, all are understandable Bulgarian, so this is entirely optional.

Based on learnings, ildyria does not prioritize strict localization consistency for translation files, so no action is required.

Also applies to: 99-100, 153-154, 233-236

lang/ja/all_settings.php (1)

127-127: Stale + typo in SA_random_thumbs doc string not caught by the rename.

Line 127 still reads 'stared/sorting order' — stared is a typo of starred, and since this PR renames the whole concept to "highlighted", the string should be updated accordingly.

✏️ Suggested fix

-        'SA_random_thumbs' => 'Use random thumbs instead of stared/sorting order.',
+        'SA_random_thumbs' => 'Use random thumbs instead of highlighted/sorting order.',

resources/views/includes/svg.blade.php (1)

199-203: Consider adding a star-0 symbol for the "no rating" state.

The PR introduces a 1–5 rating system. If the UI needs to represent an unrated photo (rating = 0 / null) with a consistent icon — e.g. an empty or greyed-out star badge — there is currently no star-0 symbol. The existing star symbol (line 198) is a full-size star and doesn't match the mini-star badge style of the new series.

resources/js/components/gallery/albumModule/PhotoThumbPanelControl.vue (1)

3-16: Consider hiding the highlighted button when there are no highlighted photos.

The star rating filter (lines 17-36) is gated by v-if="photosStore.hasRatedPhotos", but the highlighted filter button is visible whenever the user has the right permissions, even if highlightedPhotosCount is 0. This shows a "🏳 0" button that may confuse users when no photos are highlighted.

Consider adding && photosStore.highlightedPhotosCount > 0 to the v-if condition, or a similar computed check, to mirror the star filter's behavior.

Suggested change

 	<div
 		class="inline-flex items-center gap-0.5 pr-2 mr-2 border-r border-neutral-300 dark:border-neutral-600 h-8"
-		v-if="lycheeStore.is_se_enabled && (albumsStore.rootRights?.can_highlight || albumStore.album?.rights?.can_edit)"
+		v-if="lycheeStore.is_se_enabled && (albumsStore.rootRights?.can_highlight || albumStore.album?.rights?.can_edit) && photosStore.highlightedPhotosCount > 0"
 	>

lang/es/gallery.php (1)

45-45: Translation value retained from the old starred key.

'Sembrado de estrellas' (literally "strewn with stars") was the pre-existing label and is now reused under the highlighted key. Consider updating this to a semantically accurate Spanish equivalent (e.g., "Destacadas") in a follow-up.

lang/zh_TW/gallery.php (1)

153-154: Values still use "Star"/"Unstar" under the renamed highlight/unhighlight keys.

lang/zh_TW/gallery.php was already using English fallbacks for these entries and that hasn't changed. Consider updating these (and the corresponding menus entries at Lines 233–236) to reflect "highlight" semantics in a follow-up translation pass.

lang/de/gallery.php (1)

152-153: Inconsistency between photo.actions and menus translations.

photo.actions.highlight → "Mit Stern bewerten" (Rate with a star) while menus.highlight → "Favorit hinzufügen" (Add to favorites). This discrepancy is pre-existing (carried forward values) but now more visible under the unified highlight/highlighted key set. Consider aligning them in a follow-up translation pass.

database/migrations/2026_02_22_100000_rename_starred_to_highlighted.php (2)

93-104: Step 2: Rating recomputation issues N+1 queries per chunk but acceptable for a one-time migration.

Each row triggers a separate UPDATE (line 100-102). For very large datasets this could be slow. A single raw UPDATE ... JOIN would be faster, but for a migration this is fine.

♻️ Optional: single UPDATE with JOIN (MySQL/PostgreSQL)

For MySQL:

UPDATE photos
JOIN statistics ON photos.id = statistics.photo_id
SET photos.rating_avg = ROUND(statistics.rating_sum / statistics.rating_count, 4)
WHERE statistics.rating_count > 0;

For PostgreSQL:

UPDATE photos
SET rating_avg = ROUND(statistics.rating_sum::numeric / statistics.rating_count, 4)
FROM statistics
WHERE photos.id = statistics.photo_id AND statistics.rating_count > 0;

This would replace the entire chunk loop with a single statement.

---

124-135: Index names contain album_id but the indexes no longer include album_id column.

The index names like photos_album_id_is_highlighted_index (line 126) are misleading since album_id was dropped in the prior migration and these indexes only cover is_highlighted (+ other columns). This was inherited from the earlier migration, but it could cause confusion for future maintainers.

resources/js/composables/contextMenus/contextMenu.ts (1)

21-32: PhotoCallbacks type still uses star/unstar — rename to highlight/unhighlight for consistency.

The feature has been renamed throughout the stack, but the exported PhotoCallbacks type and the property references on lines 99, 106, 199, and 206 still use the old names. This creates a mismatch between the external API name and the feature semantics.

♻️ Proposed rename

 export type PhotoCallbacks = {
-	star: () => void;
-	unstar: () => void;
+	highlight: () => void;
+	unhighlight: () => void;
 	setAsCover: () => void;

And update the four usages in photoMenu and photosMenu:

-			callback: photoCallbacks.unstar,
+			callback: photoCallbacks.unhighlight,

-			callback: photoCallbacks.star,
+			callback: photoCallbacks.highlight,

Note: all call sites that pass a PhotoCallbacks object will need a corresponding rename.

resources/js/composables/album/photoActions.ts (1)

15-28: Rename newStarValue to match highlight semantics.
Keeps terminology consistent after the star → highlight rename.

♻️ Suggested rename for clarity

-		const newStarValue = !photoStore.photo.is_highlighted;
-		PhotoService.highlight([photoStore.photo.id], newStarValue).then(() => {
+		const newHighlightValue = !photoStore.photo.is_highlighted;
+		PhotoService.highlight([photoStore.photo.id], newHighlightValue).then(() => {
 			// Update the current photo store
-			photoStore.photo!.is_highlighted = newStarValue;
+			photoStore.photo!.is_highlighted = newHighlightValue;

 			// Update the photo in the album list (photosStore) to keep it in sync
 			const photoIndex = photosStore.photos.findIndex((p) => p.id === photoStore.photo!.id);
 			if (photoIndex !== -1) {
-				photosStore.photos[photoIndex].is_highlighted = newStarValue;
+				photosStore.photos[photoIndex].is_highlighted = newHighlightValue;
 			}

Also applies to: 102-103

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

database/migrations/2026_02_22_100000_rename_starred_to_highlighted.php (1)

55-86: ⚠️ Potential issue | 🔴 Critical

$insert is overwritten on every iteration — only the last starred photo per chunk gets a rating row (still unresolved from the previous review).

The three interrelated bugs remain:

1. Line 67: $insert = [...] replaces the array each loop; only the final non-skipped photo ends up in $insert.
2. Line 75: insert($insert) is called unconditionally, even when all chunk photos were skipped and $insert is still [].
3. Line 78: array_column($insert, 'photo_id') is called on a flat associative array, so it always returns [] — making the rating_sum/rating_count increments no-ops on every chunk.

🐛 Proposed fix

 					->chunk(500, function ($photos) {
 						$insert = [];
 						foreach ($photos as $photo) {
 							$exists = DB::table('photo_ratings')
 								->where('photo_id', '=', $photo->id)
 								->where('user_id', '=', $photo->owner_id)
 								->exists();
 
 							if ($exists) {
 								continue;
 							}
 
-							$insert = [
+							$insert[] = [
 								'photo_id' => $photo->id,
 								'user_id' => $photo->owner_id,
 								'rating' => 5,
 							];
 						}
 
+						if ($insert === []) {
+							return;
+						}
+
 						// Insert the 5-star rating
 						DB::table('photo_ratings')->insert($insert);
 
 						// Update statistics aggregate
 						$photo_ids = array_column($insert, 'photo_id');
 						DB::table('statistics')
 							->whereIn('photo_id', $photo_ids)
 							->increment('rating_sum', 5);
 
 						DB::table('statistics')
 							->whereIn('photo_id', $photo_ids)
 							->increment('rating_count', 1);
 					});

database/migrations/2026_02_22_100000_rename_starred_to_highlighted.php (1)

98-104: Step 2 issues N individual UPDATE per row — consider a single JOIN-based UPDATE.

The inner DB::table('photos')->where(...)->update(...) loop inside the chunk fires one round-trip per row. For a large installation this could be very slow. A set-based update avoids the N+1 pattern:

♻️ Proposed refactor

-		DB::table('photos')
-			->join('statistics', 'photos.id', '=', 'statistics.photo_id')
-			->where('statistics.rating_count', '>', 0)
-			->select('photos.id', 'statistics.rating_sum', 'statistics.rating_count')
-			->orderBy('photos.id')
-			->chunk(500, function ($rows) {
-				foreach ($rows as $row) {
-					DB::table('photos')
-						->where('id', '=', $row->id)
-						->update(['rating_avg' => round($row->rating_sum / $row->rating_count, 4)]);
-				}
-			});
+		// Single set-based update using a JOIN (MySQL / SQLite 3.33+ / PostgreSQL)
+		DB::statement('
+			UPDATE photos
+			JOIN statistics ON photos.id = statistics.photo_id
+			SET photos.rating_avg = ROUND(statistics.rating_sum / statistics.rating_count, 4)
+			WHERE statistics.rating_count > 0
+		');

Note: the exact syntax varies by driver. If the project supports multiple RDBMS, keep a driver branch or use the chunked approach but batch the UPDATEs with upsert() / a CASE WHEN expression.

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

docs/specs/3-reference/api-design.md (1)

329-329: LGTM — footer date updated to February 24, 2026.

The --- separator and *Last updated: February 24, 2026* footer satisfy the project's documentation guidelines.

resources/js/components/gallery/photoModule/PhotoPanel.vue (1)

33-33: ⚠️ Potential issue | 🔴 Critical

@toggle-star on Dock is stale — highlight toggle from the dock won't fire.

Dock.vue emits toggleHighlight (kebab-case: toggle-highlight), but this line still binds @toggle-star. The fix on Line 3 was applied correctly but this one was missed.

Proposed fix

-			`@toggle-star`="emits('toggleHighlight')"
+			`@toggle-highlight`="emits('toggleHighlight')"

database/migrations/2026_02_22_100000_rename_starred_to_highlighted.php (1)

194-196: Add a hasColumn guard before renaming in down().
Unconditional rename at Line 194-196 can throw on partial rollbacks.

resources/js/views/gallery-panels/Timeline.vue (1)

326-335: Rename the star / unstar callback keys to highlight / unhighlight for consistency.

The callback bodies correctly call PhotoService.highlight(...), but the property names star and unstar create inconsistency that could confuse future maintainers. Note that EmptyPhotoCallbacks in resources/js/utils/Helpers.ts also defines these same keys and will need updating.

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro