Language file issues

Just wondering if anyone out there is having issues where updating a string in studio and it not updating the string on the UI?  I noticed that the string I was updating appeared in half a dozen files but when I update the string in studio it updates it in en_us.lang.php.  Then all the files that this mod_string appears in and the en_us.lang.php get "compiled" into the ext file.  But the en_us.lang.php changes appear BEFORE other instances so while en_us.lang.php has the right thing in it the old value still appears on the screen....

Does that make sense and is anyone else seeing this?  It seems to happen more with relationships than anything else.

Parents
  • I cant stand the chaos anymore so like all things I scripted my way out of it.  Deleted 18,000 unneeded language files and made it so that there is only copy of each string (the correct copy) in the language files.

    github.com/.../SugarCRM_LangFileRepair

  • Thansk for this script. We had similar issues in the past mostly due to module packages that featured the same lists, but in different named files and we would end up with a complete mess. What we found out was that ( if I recall correctly) the version you can edit in the studio is always the version that was changed the last ( date/time on serverfile and that would also be the last version of that dropdown / language setting in the compiled version. So we ended up with a script that lets us select which languages we want and it then uses the collected versions to regenerate the language files in with names like en_US.lang.php or nl_NL.lang.php which contained only one instance of the same dropdown. Your script does something similar. Great work!

  • Problem with that is VCS and Jenkins.  All of our files on the production server (all servers really) have the same date as they are all pushed out from GIT each deployment.  Then we have changes by developers through VCS and admin live on studio.

    Then you have all the duplication in language files that are created by studio, especialy by relationships.

    So I decided to use the predictable file names to find the correct language strings.  It requires that I have some rules for developers so they dont add strings randomly but thats pretty easy.

Reply
  • Problem with that is VCS and Jenkins.  All of our files on the production server (all servers really) have the same date as they are all pushed out from GIT each deployment.  Then we have changes by developers through VCS and admin live on studio.

    Then you have all the duplication in language files that are created by studio, especialy by relationships.

    So I decided to use the predictable file names to find the correct language strings.  It requires that I have some rules for developers so they dont add strings randomly but thats pretty easy.

Children
No Data