Open GoogleCodeExporter opened 8 years ago
"All the munki tools then just need to check if the given item is a string or a
dictionary and then use the right language."
To not break backwards compatibility the existing string fields must remain
as-is. We'd need to define new keys for the localized versions. These keys
would be optional, and of course ignored by older clients.
What does this mean? "All the munki tools"
I imagined only that Managed Software Center would care about the translations.
Extending munkiimport to allow adding additional languages for display_name,
description, category and developer seems difficult... probably not something
I'd tackle immediately. (hard to get a feel for how something I don't use
should actually work)
(And this brings up an interesting point: while Managed Software Center runs as
the current user, /usr/local/munki/managedsoftwareupdate runs as root. It
broadcasts its status messages, which interested processes can pick up and
display. At the loginwindow, MunkiStatus is also running as root. Therefore the
user's localization choices might not actually be reflected in the status
messages (which I think would be mostly limited to display_name).)
Original comment by gregnea...@mac.com
on 3 Sep 2014 at 4:47
Backwards compatibility is a good point, so the new key containing the
dictionary might look like "display_name_localized", "description_localized"
etc.
"All the munki tools" meant "All munki tools that display information to the
end user" ;-) (what may be just MSC, I actually don't know)
I don't think that munkiimport should handle those new fields.
For the processes running in login window a translation would be nice, too. But
they are not as important as MSC, I guess.
Original comment by choules@wycomco.de
on 3 Sep 2014 at 5:02
Original issue reported on code.google.com by
choules@wycomco.de
on 3 Sep 2014 at 4:37