Re: Screenshots for 1.3, page layout

[Chris Travers <..hidden..>]

On Wed, Apr 1, 2009 at 3:43 AM, Ed W <..hidden..> wrote:
> Hi
>
>> First before I begin, I like your general suggestion to line up
>> fields.  Unfortunately, I also think it will take us some time to get
>> this exactly implemented.
>>
>
> I think it's a complete non issue.  Just like you guys are discussing
> for the English, the translator has the same constraint to simply take a
> base translation and then fiddle around until the words fit the space
> available.  If they have to use abbrv's then they will do so...
>
> Put a stake in the ground and run with it
>
> A cheap hack for the gettext contexts would be to do two lookups, one
> with the field name concatenated with the page name, eg "Account
> Number{Create Invoice}" and again if that fails with just the field
> name.  This way you have the ability to override the field name per
> form.  The form names should also match the CSS classes for convenience

There is a standard solution for this problem in gettext and it is
called "contexts." BTW, the most recent versions of the libraries we
use support contexts.  However, the fact is that our codebase doesn't
yet support contexts, and we have more discussion work to do to make
that work in a proper way.  In essence we need to figure out HOW we
want contexts to work, and backtrack from there.  This is going to
take both design and coding work, and I don't see it happening before
1.4.

I still think a better approach is to allow for language-specific css
files, and handle alignment in css rather than in the fieldname
length.  We can then support contexts, so that translators can, if
they want, provide alternate labels for specific fields.

>
> Why not just wrap each page in a div and attach a class.  One class (or
> ID more likely) gives you the name of the form you are editing, another
> class gives you the language.

ummm....  I don't think we are talking about the same problem.  Each
row is a div, and each input/label combination is a div too, iirc (but
one displayed inline rather than block).   We have the required
specificity necessary to do per-language alignment, and it is just a
matter of where to put the css files.

Personally I would rather NOT put all the language-specific CSS in the
same file......

>
> Now if you need every label 3 feet wider on the german page you simply
> tweak the CSS appropriately...  More specific classes naturally override
> less specific, so this should tend to work as expected with few surprises

Sure, but the question is how to factor the CSS then.  I am suggesting
something entirely different which is to include different css files
for different languages.  That way German and English label widths
don't need to be maintained in the same file.  If we have different
files, we can just include a link tag which brings in the one we need
each time, and only for the appropriate screen.

>
> Bonus marks if you only include the extra language CSS files if actually
> required rather than for every page refresh.

That is fairly close to what I am proposing.  Detect the user's
language and include a single css file specific to that language.

Best Wishes,
Chris Travers