Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 327924 - Localization Files Editor allows users to create keys with spaces
Summary: Localization Files Editor allows users to create keys with spaces
Status: RESOLVED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Sequoyah (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-15 13:24 EDT by Vinicius Hernandes CLA
Modified: 2016-11-08 14:46 EST (History)
4 users (show)

See Also:

Attachments
Fix for this bug (16.36 KB, patch)
2010-10-18 07:56 EDT, Vinicius Hernandes CLA 		wmg040: iplog+
Details | Diff
Little change in the fix for this bug (6.77 KB, patch)
2010-10-18 11:33 EDT, Vinicius Hernandes CLA 		wmg040: iplog+
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 Vinicius Hernandes CLA 2010-10-15 13:24:28 EDT 
Build Identifier: 

LFE allows users to create keys with spaces in the name, resulting in a R.java error for Android applications.

Reproducible: Always
Comment 1 Vinicius Hernandes CLA 2010-10-18 07:56:12 EDT 
Created attachment 181085 [details]
Fix for this bug

A new abstract method was added to ILocalizationSchema  [boolean keyAcceptsBlankSpaces()]. All localization schemas must implement this method, returning true if keys with blank spaces are permitted in that schema or false otherwise. The "New key" dialog was also modified to validate that accordingly, displaying a message to the user in case the key has blank spaces but it's not permitted.
Comment 2 Vinicius Hernandes CLA 2010-10-18 11:33:59 EDT 
Created attachment 181106 [details]
Little change in the fix for this bug

Adding a default implementation for keyAcceptsBlankSpaces() returning false as the default. This way, new localization schemas don't need to implement that, they only override the method if they want to change the default behavior. Additionally, it doesn't break the API for existent localization schemas either.
Comment 3 Eric Cloninger CLA 2011-01-19 13:28:52 EST 
+1 from Eric Cloninger
Comment 4 Marcel Gorri CLA 2011-01-20 10:44:32 EST 
Fix already integrated on trunk and on branch 3.6_SR.