GNOME Bugzilla – Bug 740510
Localization String Updates
Last modified: 2019-02-22 05:14:12 UTC
Created attachment 291202 [details] [review] update localization OSX is now case sensitive, so .string files must be named "GtkosxApplication." Also changes must be made to Quit and Hide items to account for the automatic adding of the application name in a way that word order can be accounted for in the given language. Updated strings come from GIMP. Thanks to Kevin Berningham who did the code. If this patch is in an incorrect format please let me know, I tried my best, but I'm very much a novice with this sort of thing.
It's not, but I can work with it. OSX is not now case sensitive by default. It is and always has been case preserving unless one deliberately formats a partition as case sensitive, which a few people do in order to make it a little more like traditional unix.
Believe it or not I just got the email from bugzilla, The mailing list came a lot faster. Anyway, strange that my filing system wasn't case sensitive, but it was ignoring the .iproj folders until we renamed them.
Er..the .string files inside them to be more accurate.
I think the localization API ends up using CFCopyLocalizedStringFromTable, which is case sensitive. https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFBundleRef/#//apple_ref/c/macro/CFCopyLocalizedStringFromTable Rather than rename the files, you could change the source to use "GtkOSXApplication". The first Services title lookup still does. I would not format an HFS boot disk as case sensitive. It is likely to cause trouble. My understanding is that file content changes should be committed separately from renames anyway.
That would sound good to me, whatever John wants to do.
Created attachment 291293 [details] [review] Just the strings and string file update by itself
If it's any help I made a diff patch with just the string update by itself. I fear I do not know enough about the code to change what the string file title should be in the source code. Better for me not to mess with things I don't understand.
Excellent! I finally found a proper tutorial on how to create a patch with git, It's quite a bit more involved then I thought. I hope this still helps. John if it's ok with you I'll let the decision to either change the name of the string files or change the code rest with you.
Created attachment 291296 [details] [review] Just the strings and string file update by itself
Dang it! I should have looked at the patch after running 'git format-patch HEAD^' it thought the string files were binaries again. Sorry for the clutter.
Created attachment 291297 [details] [review] Just the strings and string file update by itself
I'm sure people are busy, but is there any word on this? Is there anything else needed?
Yes, I've been busy. Tested today, seems to work, pushed.
Ok thanks! Github it claims the string files are binary files, but they seem to be ok. Also I don't know if you want to change the name in the source, or change the name of the files. Either would be fine.
It thinks that because they use wchars, which git doesn't understand. It's not important. I need to experiment with the filenames in git. I can easily accomplish the change in Linux, which is case sensitive, but I'm worried that it will cause problems when pulled into a repo on an HFS+ partition; if that's the case then I'll have to change the code instead; but I've some concern that that will cause trouble for gobject-introspection. It shouldn't, the filenames should be introspected as plain strings, but again it needs to be tested.
I got the rename to work by doing it in two stages. That's now pushed as well.
Created attachment 291811 [details] [review] update localization table name
File names need to be updated in strings/Makefile.am
I checked, Kevin is right. The file names in strings/Makefile.am is still the old ones.
Kevin's patch is applied and strings/Makefile.am fixed. Anything else?
Nope, I think that's it. Happy Holidays to you!