Enter Text to be in Uppercase

Hi All,

Just a query…

I am building a form and would like for text entered to be in uppercase (CAPS LOCK).

Any options on the layout and settings or anywhere where it will allow me to set so that when a Text question is created, all text answers are automatically converted to Uppercase?

Thanks and looking forward to hearing from you all.


Hi @branno813,

Welcome back to the community! Would you mind having a look at the post that has already been discussed in the past (it should solve your issue):

As a backup you could also have a look at our support article Restricting Text Responses With Regular Expressions. It has a lot of day to day practical examples.

Have a great day!

1 Like

Hello @branno813,
In addition to the link of Kal_Lam, pay attention: Restrict an entry with upper case and special characters while entering a form
You may also see other other previous examples here:
and here

Another option might be using the translate function: https://www.w3.org/TR/1999/REC-xpath-19991116/#function-translate.
See example attached. UPPER CASE 02 (Translate).xlsx (9.3 KB)
This form can be deployed from KoBoToolbox!
But it shows a parser error in ODK XLSFormOnline https://getodk.org/xlsform/image
Maybe one of the KoBo experts can say more @Xiphware, @Kal_Lam, @stephanealoo ?
Maybe another form of path reference could work better? ( . or ${} didn’t.)
Kind regards

1 Like

Hi @wroos, cc: @branno813,

This can be done as outlined in the image below:

In the survey tab of your xlsform:

Data entry screen as seen in Enketo:

Reference xlsform:
UPPER CASE (Translate).xlsx (9.7 KB)

Have a great day!

1 Like

Hello @Kal_Lam,
I am really sorry to say. Your version could NOT be deployed temporarily.
image. But now it worked.
But it’s different to our demand (and example) to directly change the original text variable.

As I wrote in my attached XLSForm example:
Didn’t work with . Or ${} reference. Deployment error (self-reference). But works in Enketo Preview.
Also ODK Online test, shows for your ${ } version the same error as cited above.

It’s sometimes stressing, that 3 ODK/KoBo tools show different behaviour. Our lesson learnt hard is: You cannot trust by testing in Preview that the form will then work for deployment and also not that it will act the same way then in KoBoCollect and in ODK Collect.
Kind regards

But it shows a parser error in ODK XLSFormOnline https://getodk.org/xlsform/

FYI please re-try @Kal_Lam’s form on XLSForm Online. It appears to be working now. (there are some h/w & s/w issues with the server that are being looked into, but have been causing it to sometimes misbehave…).


Hello @Xiphware,
Thanks. Yes, the version of @Kal_Lam worked now (I updated the previous post).
But to create a second variable (in Uppercase) was not the solution I am looking for.

Our Question is:

  • How can we change the original text variable (Q2) to Uppercase?
    You may have a look at our example:
    UPPER CASE 02 (Translate).xlsx (9.4 KB)

  • If we use /data/Q2 (absolute path) as reference in the translate (calculation), it WORKS in Preview, can be deployed in KoBoToolbox and then works in KoBoCollect & ODK Collect, but only on SAVE/Re-Edit (not yet when moving out the field, like in Preview).

  • But it still gives an error in XLSFormOnline. (So, won’t work for deployment with ODK. But may work as XForm too?)
    If we use . or ${Q2} as reference form, it gives an error on employment in addition. (But also works in Preview).

Here the output for our XLSForm in Preview, after entering “ab” + return (or validate or just mouse-click)
(upload://lGda6S3ThR2aIutvnMHiEIqERgr.xlsx) (9.4 KB)

So, maybe there is another option for the path reference? (Or something like bind: with set_value)?? Or at least, can you confirm that this will keep working in KoBoCollect/ Enketo?

Kind regards

P.S. In summary: we have a function/constellation here, which:

  • Can be deployed with KoBoToolbox
  • Cannot be deployed with XLSForm Online
  • Works then in KoBoCollect & in ODKCollect
  • But works differently in KoBo/Enketo Preview (activated on move/click) to Collect (activated only on Save/Re-Edit only).
    My feeling is, this might be similar with other self-referencing examples.

Any idea how we can better avoid those trial-and-error experience?
Maybe new things might even happen with the example after the server updates tomorrow? :upside_down_face:

Hi @wroos
I have elaborately tested all the scenarios and we arrived at the same conclusions. As a general rule of thumb, users should avoid self-referencing in calculations, triggers, and relevant columns. As it is, we notice that the preview behavior does not mimic the Enketo behavior which is something that the developers are looking into, from a macro perspective. On a specific recommendation for this particular translate need, I recommend that you use a calculate question as earlier suggested. This one step aids in ensuring you achieve your intended goal without potential exposure to dependency issues caused by self-referencing.
You can also follow the github discussion that seems more closely related to this issue

Thanks so much for pointing this out, and for your continuous contributions on this platform.



Thanks, Stephane,
Just for the developpers: It’s also a difference between ODK Collect and KoBoCollect (esp. parser level).
Have a nice week.


Hello collegues!
Please I have the same problem.
I want to convert automatically characters with high and low accents to uppercase with
I used [translate(${Q2}, “abcdefghijklmnopqrstuvwxyz”, “ABCDEFGHIJKLMNOPQRSTUVWXYZ”)] and it works but if there’s low accent (eg: école) or (eg: élève) in the text, it can’t convert.
Please I need your help

I think this might be another topic. @Kal_Lam to move?

@kassim.dogawa, could you share with the community the detail of the lower case and the upper case that you have at your end.

Hello @kassim.dogawa,
Of course, you need to enhance the translate formula with all special French letters. Here is an example working well. UPPER CASE 03 (Translate).xlsx (9.2 KB)

For the translate function see (as mentioned before): https://www.w3.org/TR/1999/REC-xpath-19991116/#function-translate .


I just solved the problem by adding in the syntax any kind of possible accent that could be entered and I did the test and I noticed it’s good after exporting the data. Lower case characters are converted to upper case and characters with accents are converted to upper case as well.

1 Like

Thank you @Kal_Lam
You will in my response above that I finally resolved the problem with the explanation I gave

1 Like

Thank you @wroos
It’s exactly like this I did now and it worked