Right, but it's safe to just change it in generated_resources.grd and in code because all the other locales will just fall back to the English translation in generated_resources.grd. The magic ids won't match anymore since you changed the English string so everything will just default to the English text.
On Tue, Apr 7, 2009 at 10:27 AM, Avi Drissman <[email protected]> wrote: > I don't need it immediately. I can tear apart the string at the null > characters in code for now. It'd be nice to roll the strings, but that'd > need to be done in coordination with code. > > Avi > > > On Tue, Apr 7, 2009 at 1:23 PM, Tony Chang <[email protected]> wrote: > >> You can't split or change a string without going through the whole >> translation cycle. The canonical source of translations is in the >> translation console, so even if you were to change all the .xtb files by >> hand, your change would get clobbered the next time we pulled translations >> from the translation console. >> Do you need the translation immediately or is it ok to change the .grd >> file and just wait for the translations? >> >> On Tue, Apr 7, 2009 at 8:48 AM, Avi Drissman <[email protected]> wrote: >> >>> http://dev.chromium.org/developers/design-documents/ui-localizationdescribes >>> the process of adding a resource. It goes something like this: >>> >>> 1. Add the key to a .grd file >>> 2. ??? >>> 3. Translations show up in .xtb files >>> >>> I need to split an existing key, though (one that is actually two strings >>> in the first place), and that's not helpful. I need to split >>> IDS_SAVE_PAGE_FILTER into two strings. I can change the .grd file, but all >>> the .xtbs have some magic "id" number that I can't find the origin of. Now, >>> once they're put into the generated_resources file they're matched up with >>> the tag that the grd file had, but that's too late. >>> >>> What's going on here? How do I split an existing string into two without >>> going through a whole translation cycle? >>> >>> Avi >>> >>> >>> >>> >> > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
