Forums - Thread Details
  • Replies 8 replies
  • Subscribers 319 subscribers
  • Views 1006 views
  • Users 0 members are here
Related

Language file issues

Kenneth Brill

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.

  • I had some problems in the past, I forget which version it was but some customizations were moved to a different file location and we ended up with some duplicate definitions.

    The compiled version therefore had two separate lists and they were not consistent, whichever was hit last would take effect and sometimes override the proper list which was shown in studio. Other times there were permissions issues so you would change something in studio, save, and it would just revert to the old list.

    I suggest you go to your compiled list, look for the string in question and see how many versions you can find. The ext file should tell you where it was merged from. Clean up your files by removing any additional definitions and leaving the one controlled by studio.

    Hope this helps you dig in the right direction a little...

    FrancescaS

  • 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

  • in reply to Kenneth Brill

    That is some really nice work!!

    Thanks for sharing! 

    I'll have to give this a whirl! :)

  • in reply to Kenneth Brill

    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!

  • Sugar 11 has the new *orderMapping.php files. The orderMapping.php files are to handle this issue. They keep track of when the files are added to the filesystem and then newer files are used after the older files.

  • in reply to Jeff Bickart

    I never got an answer if they extended to language files, I assume it does.   I like the idea but it still seems a bit hard to manage.  Not sure how that would work with several admins and developers working live and though VCS. 

  • in reply to Jeroen Somhorst

    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.

  • I'm working on the multi-language version of this right now, hopefully it will be available next week.