Translate: show where linked strings live when active filters don't match - #4281
Translate: show where linked strings live when active filters don't match#4281ayshushus wants to merge 17 commits into
Conversation
|
TODO
|
eemeli
left a comment
There was a problem hiding this comment.
Looks decent, though I only did a surface-level review pass here.
| {`String ${string} is in ${stringResource} (${stringProject}). ` + | ||
| (filters | ||
| ? `You're browsing ${queryLabel}, filtered by ${filters}.` | ||
| : `You're browsing ${queryLabel}.`)} |
There was a problem hiding this comment.
We should really be able to rely on our own localization system, rather than duplicating the English strings all over the place.
There was a problem hiding this comment.
Agreed. Had a meeting with Flod. Changed.
There was a problem hiding this comment.
The code still duplicates the English messages in source as well as FTL.
There was a problem hiding this comment.
Had quite the time wrapping my head around this, let me know if anything's still off, sorry for the back and forth here.
Co-authored-by: Eemeli Aro <eemeli@gmail.com>
Co-authored-by: Francesco Lodolo <flod@lodolo.net>
Co-authored-by: Francesco Lodolo <flod@lodolo.net>
eemeli
left a comment
There was a problem hiding this comment.
Mostly nitpicks left; overall looks good. See also reply on an unresolved previous comment.
| ## on screen. One description per case: hidden by filters, or living in another | ||
| ## resource, project, or outside all open projects. | ||
|
|
||
| entities-StringNotFound--description-filtered = String { $stringId } is in { $stringResource } ({ $stringProject }), but it doesn’t match your current filters. |
There was a problem hiding this comment.
We should try to differentiate at least some part of the string from the rest of the text. Can we rap the string ID and resources in a span and style them differently?
| ), | ||
| } | ||
| if requested_entity_location is not None: | ||
| response["requested_entity"] = requested_entity_location |
There was a problem hiding this comment.
Why are we passing a location in a field called requested_entity?
| ## on screen. One description per case: hidden by filters, or living in another | ||
| ## resource, project, or outside all open projects. | ||
|
|
||
| entities-StringNotFound--description-filtered = String { $stringId } is in { $stringResource } ({ $stringProject }), but it doesn’t match your current filters. |
There was a problem hiding this comment.
| entities-StringNotFound--description-filtered = String { $stringId } is in { $stringResource } ({ $stringProject }), but it doesn’t match your current filters. | |
| entities-StringNotFound--description-filtered = String with internal ID <id>{ $stringId }</id> is in <id>{ $stringResource }</id> (project <project>{ $stringProject }</project>), but it doesn’t match your current filters. |
Similar edits would apply to other strings. Right now it doesn't feel very readable.
| entities-StringNotFound--go-to-string = See string { $stringId } in { $stringResource } | ||
| entities-StringNotFound--go-to-string-hint = Search for the requested string, reset current filters. | ||
|
|
||
| entities-StringNotFound--show-matching = See other strings in { $queryLabel } |
There was a problem hiding this comment.
Can we show the name and not the slug of the project in these strings?
Co-authored-by: Francesco Lodolo <flod@lodolo.net>





Fix #2921
The
stringURL param permalinks a specific string, but shared links also carry the filters active at link time (status=missing, search, ...). When the target doesn't match those filters (e.g. link saysstatus=missingbut the string is now translated), we silently redirected to the first list entry + a toast, landing users on an unrelated string. Now surface where the string actually lives and let the user choose.Backend:
base.views._get_paginated_entities: when the requestedentityis filtered out, run a second, filter-free lookup gated only by viewability (obsolete=False,translatedresources__locale, project not disabled/system,Project.objects.visible_for(user)) and attachrequested_entity_location({pk, project slug, resource path}) to the response. Absent when the string is invalid/obsolete/not viewable, so behavior is unchanged there. Threaduserthrough for the visibility gate.State:
api/entity.ts: addRequestedEntityLocationtype, optionalrequested_entity_locationon the response.entities/actions.ts,reducer.ts: carry it ontoRECEIVE_ENTITIES, store asrequestedEntityLocation. Preserve across pages (backend only reports on page 1), clear onRESET.entities/hooks.ts:useEntityNotFound()→showwhenentity > 0 && requestedEntityLocation != null && !found.UI:
entities/components/StringNotFound.{tsx,css}: new editor-panel screen. "See string" →push({ ...emptyParams, project, resource, entity })(keep string, drop filters; navigates cross-project). "See other strings" →push({ entity: 0 })(keep filters, drop string).App.tsx: render<StringNotFound>over<Entity>/<BatchActions>whenuseEntityNotFound().show.entitieslist/EntitiesList.tsx: skip the "select first entity" redirect +ENTITY_NOT_FOUNDtoast when the string-not-found screen applies.context/Location.tsx: exportemptyParams(consumed byStringNotFound).locale/en-US/translate.ftl: addentities-StringNotFound--*strings.Tests:
test_entities_not_matching_string_reports_location: reports location when filtered out; absent when the string matches.StringNotFound.test.jsx: both navigation paths (incl. cross-project) + null-location renders nothing.