Feature Proposal: Changing the registration form for use in I18N

Motivation

Promoting changes to better support I18N in Foswiki

Description and Documentation

Changing the registration form and UserForm to enable their customization in the event of I18N. I think the ideal would choose the following names in the field UserForm: FIRSTNAME, LASTNAME, EMAIL, the instead of FirstName, LastName, Email ...

The use of capital letters will allow the definition of variable in Main.TWikiPreferences as:

    * Set FIRSTNAME = %MAKETEXT{"Firstname"}%

Thus the title of formfield view-mode can be shown in language of the user.

Examples

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: CarlinhosCecconi - 02 Nov 2008

Discussion

The proposal is not clear to me. Could you explain?

• ArthurClemens - 02 Nov 2008

Carlinhos is looking for a way to internationalise the prompt fields in the user registration form. Carlinhos, surely all you need to do is use the %MAKETEXT in the form? The field names remain the same - there is no reason for them to change, is there?

• CrawfordCurrie - 02 Nov 2008

Excuse me, but my English is not very good. I will try me explain:

When you use the name field as FirstName in UserForm (and also in the process of registering), the topic of user looks like this:

But when I use the name field as FIRSTNAME in UserForm and set the variable

    * Set FIRSTNAME = %MAKETEXT{"Firstname"}%

the localization of all the names in the field UserForm is possible, even in view of the editing mode, example:

This is only because I can define a form field using a variable:

| *Name*  | *Type*  | *Size*  | *Values*  | *Tooltip message*  | *Attributes*  |
| %FIRSTNAME% | text | 40 | | | |
| %LASTNAME% | text | 40 | | | |

This works!

• CarlinhosCecconi - 02 Nov 2008

There are a few issues with this - that depend on how the values are stored in the topic, and then how to query for those values.

for example, a TWiki application that uses query search or IF, needs to be able to use 'the one and only fieldname that is used everywhere', and doing a Search on usertopic/$FIRSTNAME =~ 'Sven' may be iffy. (and the proper solution - to use MAKETEXT would be evern worse)

One thing which I don't know if it works anymore, is that in Cairo I worked on Aliasing the form feilds - using [[ActualNameOfField][Displayed name]] - that way the Displayed name could be I8N maleable, wheil the stored, and thus searchable name would be constant.

Good suggestion Carlinhos!

• SvenDowideit - 02 Nov 2008

Using the names of fields in forms with variables,

| *Name*  | *Type*  | *Size*  | *Values*  | *Tooltip message*  | *Attributes*  |
| %FIRSTNAME% | text | 40 | | | |

I can fully use those names in searches:

%SEARCH{
"FIRSTNAME = 'Carlinhos' "
type="query" ... }%

This also works!

Similarly we could adopt the example below for metadata forms with the title and summary:

| *Name*  | *Type*  | *Size*  | *Values*  | *Tooltip message*  | *Attributes*  |
| %TITLE% | text | 40 | | | |
| %SUMMARY% | text | 40 | | | |
| %CLASSIFICATION% | text | 40 | | | |

In cases of wikis where I18N and L10N are important, these adoptions facilitate implementation.

• CarlinhosCecconi - 02 Nov 2008

Great Idea, Carlinhos!

I like the [[ActualNameOfField][ActualNameOfField]] way more than using a variable:

• There is something similar to define form values, IIRC
• I'm maturing an idea about a more efficient TML parser and using the preference way make it a little more difficult...

• GilmarSantosJr - 03 Nov 2008

using =%SUMMARY% works, yes, but has implicatios further along the code and addon system that may be a problem. The implementor of course will be responsible for investigating these options and coming to the most long term flexible solution

oh, and for that person - don't forget that [[Web.ActualNameOfField][ActualNameOfField]] the form value should work with a Web name again - that has broken once in a while.

• SvenDowideit - 03 Nov 2008

Changing this to a ParkedProposal. No developer for 7+ years. May be reasonable to revisit now that Foswiki has UNICODE support, but still needs a developer.

-- GeorgeClark - 03 Nov 2015