Closed
Bug 424542
Opened 17 years ago
Closed 14 years ago
Bookmarks manager needs a separate entry for Search:
Categories
(Firefox :: Bookmarks & History, defect)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: Tonnes, Assigned: mak)
References
Details
(Keywords: polish, Whiteboard: [strings])
Attachments
(2 files)
86.04 KB,
image/jpeg
|
Details | |
4.83 KB,
patch
|
dietrich
:
review+
Pike
:
feedback+
dietrich
:
approval2.0+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.0.12) Gecko/20070508 Firefox/1.5.0.12
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT; nl; rv:1.9b5pre) Gecko/2008032106 Minefield/3.0b5pre
Until the upcoming release, the search.label entry in bookmarks.dtd was used for both the Search sidebar as well as the bookmarks organiser. This had not been a problem, as both terms (Search) were the same and basically meant ‘find’. In 3.0, places.dtd still uses the search.label, but its meaning has become different in the organizer window compared to the sidebar as the selectable places following the search string make it stand for places _where_ to search there, instead of only _what_ to search (i.o.w. find), like the latter is used in both the bookmarks and history sidebars.
In Dutch for instance, we changed the label (looking at its meaning in the organizer) from Zoeken to Doorzoeken (for German this would mean change Suchen to Durchsuchen). The logical result of this using a shared label is that Doorzoeken also appears in the sidebar, where we would still like to see Zoeken, as we still see in the history sidebar due to its own label (find.label in history.dtd).
It seems logical to me if the new entry would be the new one currently shown for the new meaning (Doorzoeken/Durchsuchen) in the organizer, keeping the old sidebar entry and its key as they were before (even though it would make sense to use a find.label/key for those). A new access key would not be necessary, as the current one is only being used by the sidebar.
If implementing this for 3.0 is a goal, copying search.label's content to the new entry for all locales may be a quick action; localizers then can see if they want to change the content of one of them or not. Using history.dtd's find.label for the bookmarks sidebar may even be a quicker option without having the need to bother localizers, though a little risky and not a very nice one of course.
Impact:
May look minor, but compared to older versions a visible regression if search.label has already been changed for locales. Basically needed anyway if the selection buttons remain in, or it may look unfinished.
Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Reporter | ||
Updated•17 years ago
|
Component: Bookmarks → Places
Target Milestone: --- → Firefox 3
Version: unspecified → Trunk
Updated•17 years ago
|
Flags: blocking-firefox3?
Target Milestone: Firefox 3 → ---
Reporter | ||
Comment 1•17 years ago
|
||
As requested by Pike, to make things clearer (especially for Mac users).
Comment 2•17 years ago
|
||
Mike, this seems to be a problem with "searching in ..." vs "searching for ...", which, for once in our life, don't affect Polish, but German and Dutch.
There is bug 422977 about removing the places query builder, setting a dependency on that.
Depends on: 422977
Updated•17 years ago
|
QA Contact: bookmarks → places
Comment 3•17 years ago
|
||
Not an issue once we remove the query builder, will see what we end up with for v.next.
Flags: blocking-firefox3?
Reporter | ||
Comment 4•17 years ago
|
||
(In reply to comment #3)
> Not an issue once we remove the query builder, will see what we end up with for
> v.next.
Although the query builder has gone, the Search button in the library hasn’t..
Reporter | ||
Comment 5•16 years ago
|
||
Unfortunately not much has happened so far, so I was wondering if it’s too late to get this into 3.5? It can’t be that hard to either create a second search*.label entry or always use history’s find.label in the sidebar, can it?
Comment 6•16 years ago
|
||
Yes, it's too late for 3.5 for any new strings.
Comment 7•16 years ago
|
||
Let's put this on the blocking list for v.next, since this is a UX issue that should be easy to solve and improves quality in some key localizations.
Flags: blocking-firefox3.6+
Comment 9•15 years ago
|
||
> Although the query builder has gone, the Search button in the library hasn’t..
Yes it has, it's now a search field without an external button. Does that not make this bug INVALID?
Any new string work would need to be completed by September 14th if it's to make Firefox 3.6, by the way.
Assignee | ||
Comment 10•15 years ago
|
||
(In reply to comment #9)
> > Although the query builder has gone, the Search button in the library hasn’t..
>
> Yes it has, it's now a search field without an external button. Does that not
> make this bug INVALID?
when you search we still show the scope bar, so i suppose the bug applies to the Search: label in the scope bar. At least looking at screenshot in comment 1
Reporter | ||
Comment 11•15 years ago
|
||
(In reply to comment #10)
> (In reply to comment #9)
> > > Although the query builder has gone, the Search button in the library hasn’t..
> >
> > Yes it has, it's now a search field without an external button. Does that not
> > make this bug INVALID?
>
> when you search we still show the scope bar, so i suppose the bug applies to
> the Search: label in the scope bar. At least looking at screenshot in comment 1
Correct, this is about the Search label that currently shows up after entering a search phrase. So definetely not invalid IMO.
Assignee | ||
Comment 12•15 years ago
|
||
Curtis, this should land today for the string freeze, or won't block anymore.
Comment 13•15 years ago
|
||
Missed string freeze, not a blocker anymore.
Comment 14•15 years ago
|
||
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".
In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body contains places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.
Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.
Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
Comment 15•14 years ago
|
||
This is not a blocker for 1.9.3. Would take a fix before whenever string freeze is.
blocking2.0: ? → -
Reporter | ||
Comment 16•14 years ago
|
||
As this bug will affect Fx4 as well and is likely to get of the radar (again), would this be a good time to impement this?
Comment 17•14 years ago
|
||
We're really close to string freeze once more, and I guess it won't block fx4.
If we'd get a patch real quick, we might be able to slip it in, though.
Assignee | ||
Comment 18•14 years ago
|
||
omg, we still have locale/browser/history/history.dtd that is completely nonsense (sounds like inheritance from FX2). Half of those entries are unused, and the remaining ones should be merged to places.dtd.
Pike, would you accept such a change or should I limit to add a search.in.label and file a follow-up to kill history/history.dtd post FX4?
Assignee | ||
Comment 19•14 years ago
|
||
this would be the full patch, otherwise I'd just introduce search.in.label.
I'm still rebuilding to test the patch, but it should be fine.
Comment 20•14 years ago
|
||
Comment on attachment 485703 [details] [diff] [review]
full patch v1.0
Kinda sad either way, now is better than a day before the next string freeze ;-)
Attachment #485703 -
Flags: feedback?(l10n) → feedback+
Assignee | ||
Updated•14 years ago
|
Whiteboard: [strings]
Assignee | ||
Comment 21•14 years ago
|
||
Comment on attachment 485703 [details] [diff] [review]
full patch v1.0
Axel, once reviewed, do I need approval for b7 or is b8 fine?
Attachment #485703 -
Flags: review?(dietrich)
Comment 22•14 years ago
|
||
Comment on attachment 485703 [details] [diff] [review]
full patch v1.0
r+ assuming confirmation that these removed strings aren't used anymore.
Attachment #485703 -
Flags: review?(dietrich) → review+
Assignee | ||
Comment 23•14 years ago
|
||
(In reply to comment #22)
> r+ assuming confirmation that these removed strings aren't used anymore.
I did a search for each one in mxr, and manually tested history sidebar, without noticing any glitch or missing string.
Comment 24•14 years ago
|
||
We can't land this on just b8 unless we built b7. So either both, or wait 'til b7 is out the door.
Assignee | ||
Comment 25•14 years ago
|
||
Comment on attachment 485703 [details] [diff] [review]
full patch v1.0
ok ,then asking review to land on central and b7, or otherwise, if we feel better waiting, only for central once b7 is out (not sure why we can't land on central while b7 is not out, is this related to issues with l10n dashboards distinguishing branches?).
Please specify what you prefer me doing.
Attachment #485703 -
Flags: approval2.0?
Updated•14 years ago
|
Attachment #485703 -
Flags: approval2.0? → approval2.0+
Comment 26•14 years ago
|
||
a=beltzner for mozilla-central default and GECKO20b7pre_20101006_RELBRANCH
Assignee | ||
Comment 27•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/3d56a8182a7a
Looks like we don't have anymore to land to b7 branch from what I was told. Let me know if i'm wrong.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment 28•14 years ago
|
||
> Looks like we don't have anymore to land to b7 branch from what I was told. Let
> me know if i'm wrong.
You're not wrong. I'll post to dev-planning about this soon.
Comment 29•14 years ago
|
||
(In reply to comment #2)
> Mike, this seems to be a problem with "searching in ..." vs "searching for
> ...", which, for once in our life, don't affect Polish, but German and Dutch.
FWIW, it affects Polish, too. "Search in $foo" would be "Przeszukaj $foo" or "Szukaj w $foo" and "Search for $foo" would be "Szukaj $foo" / "Wyszukaj $foo" / "Znajdź $foo".
The form we used until now ("Przeszukaj:") ended with a colon which somehow made it kind of (but not really) fit both situations.
Now it's much better. Thank you, Marco, for fixing this. :)
Assignee | ||
Comment 30•14 years ago
|
||
you're welcome, keep up the good work with localization :)
Reporter | ||
Comment 31•14 years ago
|
||
Thanks all. :)
You need to log in
before you can comment on or make changes to this bug.
Description
•