Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

Potlatch can't handle i18n strings which overflow the boundaries of its dialog boxes which are hardcoded for English #2067

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 4 comments

Comments

@openstreetmap-trac
Copy link

Reporter: avarab[at]gmail.com
[Submitted to the original trac issue database at 7.50pm, Tuesday, 14th July 2009]

From localised.yaml:

"prompt_helpavailable": Nr notandi? Skoau hjlpina me v a smella  hjlpartakkann nest til vinstri.

Then see the screenshot.

@openstreetmap-trac
Copy link
Author

Author: avarab[at]gmail.com
[Added to the original trac issue at 10.53pm, Tuesday, 14th July 2009]

This seems to be a systemic problem in Potlatch, e.g. editinglive exhibits the same problem.

To reproduce it just try making every string in some Potlatch locale twice as long as it currently is and watch it screw everything up.

@openstreetmap-trac
Copy link
Author

Author: Richard
[Added to the original trac issue at 5.53pm, Tuesday, 4th August 2009]

This is kinda inevitable, I'm afraid, unless you either a) have a whole UI framework to sort this out, or b) make all the dialog boxes very big for the most verbose language.

ActionScript 1 doesn't have such a framework and I don't have the time or energy to code one. Potlatch 2 will use the Flex framework for ActionScript 3 which should probably do a better job of sorting this out.

Until then, though, there are two quick wins:

  • Are there any particular dialogue boxes which are consistently too small, and where a reasonable amount of enlargement would improve usability for many users without compromising it for others?
  • Are there any textfields which are actually too small and the text is being cropped rather than just overflowing?

@openstreetmap-trac
Copy link
Author

Author: avarab[at]gmail.com
[Added to the original trac issue at 8.04pm, Tuesday, 4th August 2009]

Replying to [comment:3 Richard]:

This is kinda inevitable, I'm afraid, unless you either a) have a whole UI framework to sort this out, or b) make all the dialog boxes very big for the most verbose language.

One workaround which might be viable would be to take the length of the string into account whenever you create text fields with [http://livedocs.adobe.com/flashlite/2/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000623.html createTextField], for instance here:

    function setEditingStatus(str,col) {
        _root.createEmptyMovieClip("status",62);
        _root.status.createTextField("btext",1,0,-1,90,20);
        with (_root.status.btext) {
            text=str;
            setTextFormat(boldWhite);
            selectable=false; type='dynamic';
        };

Instead of hardcoding 90' you could determine the width based on the length of 'str. How long you can get away with that before doing collision detection I don't know.

ActionScript 1 doesn't have such a framework and I don't have the time or energy to code one. Potlatch 2 will use the Flex framework for ActionScript 3 which should probably do a better job of sorting this out.

Until then, though, there are two quick wins:

  • Are there any particular dialogue boxes which are consistently too small, and where a reasonable amount of enlargement would improve usability for many users without compromising it for others?

I filed this bug on general terms since it seemed to me to be a general problem (and I stopped translating Potlatch as soon as I noticed that I couldn't do so due to this bug).

Pretty much all the i18n strings in Potlatch have a corresponding call to createTextField which will have its width hardcoded to whatever just about fits for the English string. To see this in action try to apply this patch to localise2.pl:

$ svn diff
Index: localise2.pl
===================================================================
--- localise2.pl    (revision 16600)
+++ localise2.pl    (working copy)
@@ -43,7 +43,7 @
            while ($tr=~/\%([^%]+)\%/g) { $tr=~s/\%([^%]+)\%/\$$substitute/;
                                          $substitute++; }
            unless (exists $translations{$lang}) { $translations{$lang}=''; }
-           $translations{$lang}.="\"$id\": $tr\n";
+           $translations{$lang}.="\"$id\": FOOBAR $tr\n";
        }
        unless ($ct) { print "WARNING: no translations read\n"; }
    }

(Incidentally this will also give you a clear indication of what strings are currently untranslatable)

Just adding 7 characters to every string in the program will almost universally cause Potlatch to overflow its UI elements.

@openstreetmap-trac
Copy link
Author

Author: Richard
[Added to the original trac issue at 7.04pm, Sunday, 30th August 2009]

For those strings that are displayed on a single line in the English version (i.e. most of them), I hope I've fixed it in 1.2a - to be committed this evening.

(This will sometimes mean the text overflows the bounds of the dialogue box. Shit happens.)

For those which are displayed on more than one line, it's not practical to programmatically resize the textField in case of overflow. That would require a whole UI framework malarkey. So I'll need to enlarge the textField to the largest practical extent - assuming that the translators aren't too prolix :) - and would appreciate feedback on this.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant