[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[zanata-bugs] [Bug 1035959] [RFE] Zanata should recognise file types individually, not from the target project



https://bugzilla.redhat.com/show_bug.cgi?id=1035959



--- Comment #4 from Sean Flanigan <sflaniga redhat com> ---
One minor thing: we also plan to have the client upload its idea of the project
type, so that the server can store it (for projects where projectType is null).

Also, we will have to make a big improvement to the client's support for File
type projects.  At present, File projects may not have any overlap between
source and translation directories: translation directories are always
completely separate from source directories, and the translated filename is the
same as the source filename, but with a locale directory at the front.

In other words, for a source file:
  src/abc/xyz.odt

The translated files will be:
  translated/de/abc/xyz.odt
  translated/fr/abc/xyz.odt
etc.

That's okay for ODT files, but it won't work for .properties files, because the
locale is expected to become part of the filename, not the directory name.  So
we may need a customisable way of specifying the template for the pathname.


Also, when there is overlap between source and translated directories, you need
a mechanism to avoid treating translated files as if they were source files.

For instance, try to upload the files:

  abc/client_messages.properties
  abc/client_messages_de.properties

As a Java programmer, I know the first one is a source file, and the second is
a translation file, but telling them apart programatically is quite difficult. 
We have something implemented as part of the current Properties support (it
uses the list of locales found in zanata.xml), but this would need to be
adapted or reinvented to work with File projects.  (Instead of looking at
zanata.xml, perhaps we could see whether part of the filename "looks like" a
locale code.)  NB: these rules may need to differ between file types, since
most file types don't use underscores to delimit locales.

As a simplification, we could start by disallowing overlaps between source and
translation, but this limitation will have to be removed before we can use File
projects for a typical Java software project.

We should check what other projects do to handle these problems.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=uG97I8bDEn&a=cc_unsubscribe


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]