User-specific Date --- different language not writing properly as "Column" value in Form

I’m running into issues where users are asked to enter a date into a User-Specific column. In my region, English is the primary language and French is secondary, but widely used as well. The issue arises when a French device enters the date into the User-Specific column. This column gets passed to a form submission as a Column value (the data is captured on the previous screen and brought into the form’s submission automatically as a “Column” value).

When an English user submits the form, the date value gets placed into the Glide Table for submissions properly. When a French user submits the form, the value is blank, but when I double click the cell in the Glide Table, the data is there and is printed out as the date written in plain text — the Glide Date column is not seeing it as a valid Date to use. See screenshots below where the top row is a French user, others are English.

Blank cell in Glide Table, causing computed columns (like the Template column beside it) to be blank as well.
image

After clicking into the cell (data is there, but is not seen as a Date):
image

3 Likes

I really think there needs to be a language setting in the GDE Date columns to force the Editor to translate a date into one language/setting so that corresponding relations and filtering are still applicable and functional. For my use case, I need to calculate dates dynamically based on a user-inputted value (user enters May 3, 2021 into a date field… math formula provides a list of seven dates from that entered date forward). Even if I use a Template column to lock in those dates as text, they get locked in as the user’s language and don’t match other entries from other English-speaking users.

If the Date column in GDE could include a “Convert to US English Date Format” it would honestly solve a world of problems.

Just out of curiosity, are your users manually typing a date in, or using the date picker?

Ugh, please no. ISO 8601

They’re actually using a choice component to select a possible range of dates. Once a range is selected, the list of possible dates is given in an inline list (the list of dates is generated from a math formula to add a number to the chosen date, so that I can get [day], [day] + 1, [day] + 2, etc.).

As long as there’s a way to ensure consistency, the format in the Editor won’t matter. When users are able to generate different formats in a column, it leads to errors. Even Glide can’t figure out the French long format to be able to display it properly in a cell (my original post above).

1 Like

YYYY/MM/DD

Problem solved. :wink:

1 Like

Quick update — @George_B got back to me through Support and indicated that Glide is aware of the issues with dates and languages, but that it’s a long-term project to rectify the problems with no ETA for broad fixes to roll out. Understandable, but frustrating nonetheless!

I decided to create a workaround for my use case (the need to capture both English and French submissions of dates and have them play nicely together). To do it, I had to create 6 new columns in my Table — one to get the day of the week (MATH), one to get the year (MATH), an IF-THEN column to change the written day of the week from French to English, another IF-THEN column to do the same with the months, a TEMPLATE column to build the English date in long format, then a final IF-THEN to only use that new template column if one of the French columns isn’t empty (so if the person is English, just use the English date as per usual).

This workaround works, but only for one more language. The same could be done for other languages, it would just be a matter of expanding the IF-THEN columns to include more checks for different translations. The best part is that someone can submit a form multiple times in multiple languages and the final Submissions Table only has English data in it ---- this makes relations, rollups, etc. much more dependable.

2 Likes

Closing due to inactivity. This topic will be deleted in a few weeks if there are no more comments.