Isolate Strings from layouts

[GoogleCodeExporter]

Hi,

I think having the strings for the buttons hard coded at the layout files will 
cause some problems when trying to fix some other issues regarding layouts / 
screen resolutions and screen orientation.

I already isolated the English strings from "xml/default_buttons_layout.xml" 
and added them to "values/strings.xml"

Additionaly there is a small fix needed in UserDefinedLayoutReader.java to have 
the xml files work with "@string/btn_test" like labels.

I attached the two changed xml files and a quick fix for 
UserDefinedLayoutReader.java.

If all Strings are completely moved from the 
"xml-xx/default_buttons_layout.xml" files to the corresponding 
"values-xx/strings.xml" there will be more possibilities to fix some other 
issues regarding the layout.
See issue #42 as an example.

The fix on UserDefinedLayoutReader.java is just a quick fix.

Best regards
Matthias

Original issue reported on code.google.com by matthias...@gmail.com on 27 Jul 2010 at 9:39

Attachments:

• strings.xml
• default_buttons_layout.xml
• TrackLogger_string_layout_isolation_quickfix.patch

[GoogleCodeExporter]

Hi,

just changed some lines in UserDefinedLayoutReader.java to handle the labels as 
either string resource identifiers or as plain labels.

I think this patch could find its way into the source. This should be a good 
start to have the layouts using the strings from values/strings.xml

Best regards
Matthias

Original comment by matthias...@gmail.com on 28 Jul 2010 at 6:47

Attachments:

• layout_strings_from_values.patch

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thanks for the patch, I'm currently integrating it. However I'm not convinced 
by the changes to the layout files for multiple reasons:
* It was already using resource references in version < 0.4.x (Look at 
http://code.google.com/p/osmtracker-android/source/browse/#svn/tags/0.3.5/res/la
yout and 
http://code.google.com/p/osmtracker-android/source/browse/#svn/tags/0.3.5/res/va
lues ) and it was a real pain to convert that into the current layouts without 
resources references, and I'm really not motivated to do it back again for all 
the current translations ;-)
* Performance: According to Android SDK doc ( 
http://developer.android.com/reference/android/content/res/Resources.html#getIde
ntifier%28java.lang.String,%20java.lang.String,%20java.lang.String%29 ) and 
what I observed, looking up resources is pretty slow
* I think it over-complicates layout creation for the vast majority of the 
users, moreover as users cannot add/modify values from the strings.xml files it 
could lead to frustration
* Fixing issues like #42 can be achieved with 2 layouts reusing the same 
labels. I know it's not ideal to repeat the values, but I think it's a 
reasonable drawback, and can even help to have different values following the 
orientation to solve text wrapping problems. 

Original comment by nguillau...@gmail.com on 1 Aug 2010 at 1:40

[GoogleCodeExporter]

Again, as reported by matthias in his original post, removing hard-coded 
strings from the layouts will enable much easier fixes to layouts (issue 42).

Note that I'm talking about the standard layouts that ship with the 
application. Those strings could/should be in a resource file, which would make 
the layout independant of the translation, and simplify the translation process 
since the translators won't have to go in all those different files (see the 
translations instructions on the wiki [1] mentioning 4 different files to go 
and translate...)

On the other side, the custom layouts made by the user are mainly going to be 
used only by them (in their own language), so those don't need to have 
reference to the resource file, the strings can be hardcoded without problems. 
(this addresses your 3rd point in the previous post).

The complexity of switching from hardcoded values to resources can be handled 
by somebody else, if that's your biggest problem ;) I would volunteer to do it, 
if we decide to go this route.

Your 4th point is really not optimal in my eyes, because it forces the creation 
of TWO new layouts for each languages. Imagine you have like 20 languages, that 
would mean 40 layouts. What happens if you decide for example to remove the 
speech and notes buttons for screens that have more than 12 buttons (as seen as 
a potential fix in another issue)? You would have to change that in all 
layouts! Whereas if you don't use hardcoded strings, you would only have 2 
layouts (portrait and landscape, whatever the locale), and you could change 
that very easily.

In my eyes, the only point that is left is your second (performance-related). 
But since it's the recommended way to do translations in Android (heck, even 
the first Hello Android tutorial without translation uses aresource file for 
the only static file!), I'm not conviced it's that big of a deal...

This ended in a long post, but I guess my point is that hardcoded strings == 
bad for flexibility, forces translators to go more into the internals of the 
program (remember that a lot of translators are not developers!)

[1] http://code.google.com/p/osmtracker-android/wiki/Translating

Original comment by emilien.klein on 24 Sep 2010 at 9:12

[GoogleCodeExporter]

Thanks for your comments.

Concerning translation the translators still would need to translate multiple 
files because I don't want to have ALL the text resources in a single file. For 
example splitting Preferences strings and app String as it's currently done is 
a good thing in my opinion.

Concerning performance the thing is that we are not using a Android resource 
file here, but a custom XML file format that we parse ourselves at runtime.
Android resource files are compiled and their resource resolved at compile time 
so it's really fast at runtime, but as we have the need for custom layouts I 
had to put the layout in a separate XML file which is not a Android resource: 
It would have been probably too complicated for users to write and Android 
resource file for their own layouts, and I didn't see how compile those one 
during runtime.
Thus the layout files don't get compiled, and require the use of the previously 
mentioned method (getIdentifier()), which is slow (You can see it when running 
the application in debug mode, the screen takes seconds to appear !)

Anyway I agree that having two layouts per language is really not desirable...

Ideally I'd like to keep one layout file, containing hardcoded string, but 
which could behave differently depending on the screen orientation (Too bad 
that http://code.google.com/p/osmtracker-android/issues/detail?id=42#c5 didn't 
work). The solution proposed here 
http://code.google.com/p/osmtracker-android/issues/detail?id=42#c6 is maybe the 
best compromised, as a starting point.

Original comment by nguillau...@gmail.com on 24 Sep 2010 at 9:37

[GoogleCodeExporter]

Yes, separating the strings in different files is not the problem, but the 
translators shouldn't have to into the layout files (those files contain more 
than just the strings to translate, they contain all sorts of extra layout info 
you don't want the translators to modify). You want your translators to work on 
files like those in "res/values", specifically made for translations.

The question is why go with a custom XML format and not use the default 
translation framework? If it's to enable custom layouts to be translated, let 
those use hardcoded strings, problem fixed, no?

The last solution can be a temporary workaround. But if we don't use a specific 
layout for landscape mode because of thranslation issues, I feel there 
something deeper at stake ;) Handling landscape mode with a portrait layout is 
bound to be problematic...

Original comment by emilien.klein on 24 Sep 2010 at 9:57

[GoogleCodeExporter]

Finally had to bite the bullet for issue #189: Transifex doesn't support our 
custom layout XML format of course, so I wrote a script to replace hardcoded 
labels in the layout files and produce a corresponding strings.xml Android 
resource.

Original comment by nicolas@guillaumin.me on 16 Aug 2012 at 12:18

• Changed state: Fixed
• Added labels: v0.6.2