Open geordiemhall opened 2 years ago
GameTables_de.xlf file that look like
Is this accurate, i.e. there's no additional metadata? Would you be able to share (privately, help@poedit.net) real-life file for better testing?
You're correct in your observations as well as in this:
Ideally POEdit could also have an option to group things in the list, almost like a tree-view where you can expand/contract groups.
This is indeed the plan, together with exposing the symbolic IDs in the UI as actual IDs. As you can probably tell, there are UI artifacts from Poedit being originally for PO files only.
Doing that is a bit more work than I won't be able to fit into 3.1, but showing the symbol ID in the Notes for translators sidebar is simple enough to make it, with further improvements following.
Thanks for the response!
Yeah it seems like there's a <file>
per string table, with a single <group>
within each <file>
Which might not be ideal if the UI did expose it as an expandable tree cause you'd have a redundant group node under each file node unless POEdit did some kind of smart "flattening"?
Here's a trimmed down XLF with just that single string in it if it's useful for testing? (had to zip it for GitHub to let me upload it) UnitySampleLocExport.xlf.zip
Or if you need more strings let me know and we can maybe email it privately. Or feel free to generate your own string tables via the Unity localization package if wanting to sift through the details of their output format.
It turns out CrowdIn also don't show the name
attribute anywhere, so I suspect Unity's breaking convention a bit in how they chose to put the machine-readable ID in the id
attribute and the human-readable separately.
Or if you need more strings let me know and we can maybe email it privately.
It's always useful to have "real-life" files / sets of files to have a better understanding e.g. which parts of spec are actually used (full XLIFF 2.x is enormous spec and approximately nobody uses all of it…).
It turns out CrowdIn also don't show the name attribute anywhere, so I suspect Unity's breaking convention a bit in how they chose to put the machine-readable ID in the id attribute and the human-readable separately.
This was poor handling on Poedit's end, Unity is doing the Right Thing ™ here. Quoting the spec on the meaning of the optional name
attribute:
Resource name - the original identifier of the resource […] For example: the key in the key/value pair in a Java properties file, the ID of a string in a Windows string table, the index value of an entry in a database table, etc
…and so in 3.1, after 4c4fef37068705e4418b6a68a2f52c64938dbaa8, Poedit will prefer to use (res)name
for the ID if present.
Hi there,
We've been using XLIFF 2.0 for our translation exchange format, and our game engine (Unity) spits out an eg.
GameTables_de.xlf
file that look likeThe game engine's localization system assigns a unique number (guid) for each string, which it then puts into the
id
attribute of theunit
, but then includes the user-facing "key" we enter as thename
attribute. Each string table in the game is given its owngroup
element, with the table title in thename
attribute. The above is an entry with key "Leaderboard_RetryRequestButton" from our "UI" table.As far as I can tell there isn't a way to add additional columns to POEdit to display the
name
orid
attribute?I found a checkbox to show the "id", but it seems to just print out more of an "index within the POEdit list".
It does seem to show the
unit
'sid
attribute in the details panel when you have a row focused, along with the comment:But it'd be give translators much more context to also be able to see the key we entered.
Ideally POEdit could also have an option to group things in the list, almost like a tree-view where you can expand/contract groups. Since we might have a table (that's exported as a
<group>
element) for general UI, one for Credits, one for Dialogue, one for GameModes, one for OptionsMenu etc. and leave the group name out of the individual string keys. So exposing the group to the translators (even if just as another column instead of hierarchically) would probably also make their lives easier.Thanks!