Answers.Body: <p>If you switch off the checkbox for street parsing (as petednz suggests) the error will disappear. But if you really need the street parsing that will not help you. In that case you would need to add the en_GB to the array in <em>CRM_Core_BAO_Address</em> in an extension, like so:</p>
  
  <pre><code>  static function parseStreetAddress($streetAddress, $locale = NULL) {
  $config = CRM_Core_Config::singleton();
  /* locales supported include:
   *  en_US - http://pe.usps.com/cpim/ftp/pubs/pub28/pub28.pdf
   *  en_CA - http://www.canadapost.ca/tools/pg/manual/PGaddress-e.asp
   *  fr_CA - http://www.canadapost.ca/tools/pg/manual/PGaddress-f.asp
   *          NB: common use of comma after street number also supported
   *  default is en_US
   */
  $supportedLocalesForParsing = array('en_US', 'en_CA', 'fr_CA', 'en_GB');
  
  if (!$locale) {
    $locale = $config-&gt;lcMessages;
  }
  </code></pre>
  
  <p>and this is a bit awkward :-)</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-22T11:52:03.370Z
Answers.Text: ...and I will be loosing this change after each security update.
Answers.UserDisplayName: yurg
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-22T12:46:05.103Z
Answers.Text: Not if you put it in an extension like you should :-)
Answers.UserDisplayName: ErikH - CiviCooP
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-22T17:47:38.053Z
Answers.Text: If it's about this https://wiki.civicrm.org/confluence/display/CRMDOC/Create+a+Module+Extension, it's a bit too much overwhelming  than (for my taste). But still, whole point is excellent, since file, where this function is located (CRM\Core\BAO\Address.php) could be moved to custom php directory. Thanks!
Answers.UserDisplayName: yurg
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-22T17:56:55.273Z
Answers.Text: I can imagine it is a bit overwhelming to develop an extension but it is the way to go if you want to continue developing with and around CiviCRM :-). For the moment the custom php directory will offer you a solution, but if you get more customization go for the extension approach. There should be enough help around :-)
Answers.UserDisplayName: ErikH - CiviCooP
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-22T11:24:05.983Z
Answers.LastActivityDate: 2016-03-22T11:24:05.983Z
Answers.UserDisplayName: ErikH - CiviCooP
Body: <p>If debugging is enabled,  'Unsupported locale specified to parseStreetAddress: en_GB' message appears in some situations (add/edit contact), which scares non-techy editors. </p>
  
  <p>There are some ancient posts at civicrm forums, which describe clearly  <strong>why</strong>   this message appears, but I've not been able to find a recipe of how to stop this from popping up, apart from a general advice of "provide custom logic for parsing UK postal addresses". </p>
  
  <p>Any hint about how to hide the message, please. Thanks!</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-22T01:20:11.173Z
Comments.Text: do you have address parsing checkbox under Address Editing turned on here Admin > Localisation > Address Settings, ie civicrm/admin/setting/preferences/address?reset=1
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-22T11:50:54.663Z
Comments.Text: Yes, I have;  does it have any relationship to geo coding or it's just about slicing an address string to a fractions?
Comments.UserDisplayName: yurg
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-22T18:31:28.127Z
Comments.Text: since your error had the word 'parseStreetAddress' it seemed a good guess. if so, and if this is a factor, then i will convert this to an answer
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-25T09:58:54.863Z
Comments.Text: Well, since it has nothing to do with geocoding [which we definitely do use] , guess your answer suits perfectly in situation, where one might want a simple solution (check box un-tick, boom, done). I'd like to accept your answer as well for those, who prefers solutions available via GUI.
Comments.UserDisplayName: yurg
Tags: <error><localisation><ajax><javascript><debugging>
Title: Suppress 'Unsupported locale specified to parseStreetAddress: en_GB' message
ThreadText: # Suppress 'Unsupported locale specified to parseStreetAddress: en_GB' message
  
  (Asked by: username_0 on 2016-03-22)
  
  If debugging is enabled, 'Unsupported locale specified to parseStreetAddress: en\_GB' message appears in some situations (add/edit contact), which scares non-techy editors.
  
  There are some ancient posts at civicrm forums, which describe clearly **why** this message appears, but I've not been able to find a recipe of how to stop this from popping up, apart from a general advice of "provide custom logic for parsing UK postal addresses".
  
  Any hint about how to hide the message, please. Thanks!
  
  **Tags:** error, localisation, ajax, javascript, debugging
  
  > **Comments:**
  > **username_1**: do you have address parsing checkbox under Address Editing turned on here Admin > Localisation > Address Settings, ie civicrm/admin/setting/preferences/address?reset=1  
  > **username_0**: Yes, I have;  does it have any relationship to geo coding or it's just about slicing an address string to a fractions?  
  > **username_1**: since your error had the word 'parseStreetAddress' it seemed a good guess. if so, and if this is a factor, then i will convert this to an answer  
  > **username_0**: Well, since it has nothing to do with geocoding [which we definitely do use] , guess your answer suits perfectly in situation, where one might want a simple solution (check box un-tick, boom, done). I'd like to accept your answer as well for those, who prefers solutions available via GUI.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2016-03-22. Score: 1 | Accepted answer
  
  If you switch off the checkbox for street parsing (as username_1 suggests) the error will disappear. But if you really need the street parsing that will not help you. In that case you would need to add the en\_GB to the array in *CRM\_Core\_BAO\_Address* in an extension, like so:
  
  ```
    static function parseStreetAddress($streetAddress, $locale = NULL) {
  $config = CRM_Core_Config::singleton();
  /* locales supported include:
   *  en_US - http://pe.usps.com/cpim/ftp/pubs/pub28/pub28.pdf
   *  en_CA - http://www.canadapost.ca/tools/pg/manual/PGaddress-e.asp
   *  fr_CA - http://www.canadapost.ca/tools/pg/manual/PGaddress-f.asp
   *          NB: common use of comma after street number also supported
   *  default is en_US
   */
  $supportedLocalesForParsing = array('en_US', 'en_CA', 'fr_CA', 'en_GB');
  
  if (!$locale) {
    $locale = $config->lcMessages;
  }
  
  ```
  
  and this is a bit awkward :-)
  
  > **Comments:**
  > **username_0**: ...and I will be loosing this change after each security update.  
  > **username_2**: Not if you put it in an extension like you should :-)  
  > **username_0**: If it's about this https://wiki.civicrm.org/confluence/display/CRMDOC/Create+a+Module+Extension, it's a bit too much overwhelming  than (for my taste). But still, whole point is excellent, since file, where this function is located (CRM\Core\BAO\Address.php) could be moved to custom php directory. Thanks!  
  > **username_2**: I can imagine it is a bit overwhelming to develop an extension but it is the way to go if you want to continue developing with and around CiviCRM :-). For the moment the custom php directory will offer you a solution, but if you get more customization go for the extension approach. There should be enough help around :-)  
  
  ---
  
  