Bug 197999 - [nls tooling] Externalize Strings wizard does not properly sort/insert new entries
Summary: [nls tooling] Externalize Strings wizard does not properly sort/insert new en...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.4 M2   Edit
Assignee: Benno Baumgartner CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-26 13:31 EDT by Markus Keller CLA
Modified: 2007-09-21 04:32 EDT (History)
1 user (show)

See Also:

Attachments
fix (17.89 KB, patch)
2007-08-14 12:27 EDT, Benno Baumgartner CLA 		no flags Details | Diff
fix (30.53 KB, patch)
2007-08-29 09:47 EDT, Benno Baumgartner CLA 		no flags Details | Diff
fix (2.42 KB, patch)
2007-09-19 06:32 EDT, Benno Baumgartner CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 2007-07-26 13:31:52 EDT 
HEAD

When using the Externalize Strings wizard, the insertion point for new messages is almost always unpredictable (or the pattern is so complex that I don't understand it), see e.g. attachment 74708 [details] from bug 168515.

New entries should be added either at the end (bug 107308), or around an existing item that shares the longest common prefix with the item to insert (sort the items lexicographically to determine before/after). This strategy also behaves well when properties files are only partially sorted.
Comment 1 Dani Megert CLA 2007-07-30 02:24:04 EDT 
Bug 107308 exacty describes your problem. No need for another one.

*** This bug has been marked as a duplicate of bug 107308 ***
Comment 2 Markus Keller CLA 2007-08-06 06:16:51 EDT 
(In reply to comment #1)
> Bug 107308 exacty describes your problem. No need for another one.
> 
> *** This bug has been marked as a duplicate of bug 107308 ***

Not really.

Bug 107308 is an enhancement request for an append (don't sort) mode.
This bug shows that the current insertion logic is broken.

If this stays a dup, I'll have to raise the severity of bug 107308, since the current behavior is not acceptable.
Comment 3 Dani Megert CLA 2007-08-06 06:26:27 EDT 
You're right.
Looks like the fix for bug 89503 didn't fully make it.
Comment 4 Dani Megert CLA 2007-08-06 06:27:58 EDT 
Benno, can you have a look? Markus wants this fixed ;-)
Comment 5 Benno Baumgartner CLA 2007-08-14 12:27:31 EDT 
Created attachment 76060 [details]
fix
Comment 6 Benno Baumgartner CLA 2007-08-14 12:39:13 EDT 
fixed > I20070809-1105

I hope this will do it but keep raising bugs if you see unexpected insertions positions please.
Comment 7 Benno Baumgartner CLA 2007-08-29 09:46:32 EDT 
Grrrrrrr!
Comment 8 Benno Baumgartner CLA 2007-08-29 09:47:39 EDT 
Created attachment 77252 [details]
fix

More bugs, more fixes...
Comment 9 Benno Baumgartner CLA 2007-08-29 09:50:39 EDT 
fixed > I20070828-0800
Comment 10 Dani Megert CLA 2007-09-18 10:23:31 EDT 
This still doesn't work - at least not for the properties file. When I tried the scenario from comment 0 I got the following insertion (of FileSearchPage_0 and FileSearchPage_1) into the properties file:

...
TextSearchEngineRegistry_defaulttextsearch_label=Default Text Search
FileSearchPage_1=message


FileSearchPage_0=title
FileSearchQuery_label=File Search
...

Observe:
1. the space between the two new entries
2. the wrong order
Comment 11 Benno Baumgartner CLA 2007-09-19 06:32:35 EDT 
Created attachment 78732 [details]
fix

Trivial fix, reason is that leading new lines are not moved to the inserted keys if they are inserted after leading new lines.
Comment 12 Benno Baumgartner CLA 2007-09-19 06:37:35 EDT 
assume fixed > I20070918-0010
Comment 13 Benno Baumgartner CLA 2007-09-21 04:32:18 EDT 
verified in I20070920-0936