Primary language case

Hi. It looks like primary_language values are stored in the cccapply db as upper case, with the exception of the 'unknown' value 'x', which is stored lower. The data dictionary implies these should be lower case, not only in the examples provided, but since its suppsed to conform to ISO 639-1.

Is this is a bug? And if so, will it be fixed?

image


Answers

  • Merrie_Wales
    Merrie_Wales Moderator
    edited December 2016
    Mike,
    I am sorry, I thought I had already responded in this forum. I have talked to the Dev team, and am waiting for a response. With the Holiday's it may take a bit longer to get a response.
    mkw
  • Merrie_Wales
    Merrie_Wales Moderator
    edited February 2017
    Mike,It has been determined that a "fix" is necessary to met the ISO-639-1 standard. The developers have a "fix" ticket for this issue. If it will come out in the March release or sooner I do not know. If we get a definite date for deploy I will update this question, and put that in your HelpDesk ticket as well.
  • severa
    severa Member
    edited December 2016

    Thanks for the update Merrie. Good to know.

    And just to be clear, the fix will be to store everything in lower case?

  • Merrie_Wales
    Merrie_Wales Moderator
    edited December 2016
    Mike,I will double check with the Dev Team, and yes that is my understanding. To meet the ISO-369-1 standard they will be in lower case.
  • severa
    severa Member
    edited February 2017
    One further question here: technically the documents say that only specific language values are stored in the database. This would jibe with the fact that the options to choose from are limited. However, we are getting one that is not listed in the document (zh, I expect for Chinese). That appears to be from the ISO-639-1 standard (which in the case of Chinese the document implies should actually be from the ISO-639-3 or ISO-693-6 standards). Can you clarify whether the goal is to actually include any value that's in the ISO-639-1 standard, or is that a bug and the code should actually be one of the other two? thanks.
  • severa
    severa Member
    edited January 2017
    Btw, one thing that would help me, even before any fix is started, is to know what the eventual values in this field will be. Then I can at least modify them on our end to match that. We are in testing phase and without that our tests are useless. Is it possible to get at least that? Thanks.
  • Merrie_Wales
    Merrie_Wales Moderator
    edited January 2017
    Mike - I will see if I can get a list of the values, so LACCD can test based on that list, and I will update your Zendesk ticket. mkw
  • severa
    severa Member
    edited January 2017
    Thank you. :-)
Sign In or Register to comment.