Thanks for your reply. On 19 October 2012 22:33, Andrea Pescetti <pesce...@apache.org> wrote:
> On 17/10/2012 jan iversen wrote: > >> Would it be an idea to have 1 UI file pr directory in main (that would be >> so easy to implement) and 1 Help file pr directory in helpContent2 ? >> > > Yes, this might work. Sure the current 276 files are too many, while > consolidating too much on the other hand is very inconvenient for sharing > work. What we should preserve is that is someone is the, say, "Calc guy" in > the, say, Polish team, then he can be given PO (or other format, this is > irrelevant) files for the Calc UI and the Calc Help. This enables easy and > safe division of work. I agree...but I am not sure we can make the files for like calc, if I am correct the directories in main does not directly relate to a product part, many of the directories seems to be generic, but I might be wrong ? My intentions right now is to propose that each directory is a single translation file and helpcontent2 is split at that level, but there will be a new file combine.lst, where we can combine several directories into one. That way we are flexible but it is still easy to develop. > > > also check the letter accellerators (Ca~ncel) I have a >> very strong suspicion that they are not always identical. >> > > This is not important. Actually, if I recall correctly we even deprecated > them at a point. We are not talking about keyboard shortcuts here (e.g., > CTRL-S to open a file); we are talking about the, much less common, > "accelerators", i.e., saving with ALT-F then S. OpenOffice will assign > these accelerators automatically when they are not set using the "~" in the > strings, and it makes sense to let OpenOffice assign them, since they are > not listed in the documentation. Moreover, assigning them manually is very > error-prone since it often results in conflicts, while automatic > attribution doesn't. > Should we the consistency checker than make a warning when they are used (which happens approx. 500 times in the danish files) ?? > > Regards, > Andrea. > For your information I have found a way of splitting the discussion of a new l10n workflow from the discussion of file formats. That is I have succeed (I think) in making a workflow that does not rely on the fileformat. Jan.
