Talk:Manufacturing data: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
* Mitch Bradley approves with the qualification: All items marked TBD must be resolved. |
* Mitch Bradley approves with the qualification: All items marked TBD must be resolved. |
||
* Ivan approves, same qualification as above. |
* Ivan approves, same qualification as above. |
||
| ⚫ | |||
* Ray <approval needed> |
* Ray <approval needed> |
||
* Ron <approval needed> |
* Ron <approval needed> |
||
* Richard <approves> |
* Richard <approves> |
||
| ⚫ | |||
Add to goals: flexibility; there will be many keyboard variants, possibly a number of other variants of the base machine, with time. |
|||
I think either only text should be allowed, or if non-text values are essential and allowed, a type field should be added to the tags. |
|||
Should text be UTF-8, rather than ascii? |
|||
The wireless mac number: I presume this is the only location for the MAC address: there is no mac address in the wireless logic itself? I don't believe in dupicating information that may become inconsistent. What is the format of this string? (presuming |
|||
it is a string). |
|||
I'm not sure language is appropriate in the area at all. What is this going to be used for? |
|||
The software load has a default locale already, and multiple languages may be supported |
|||
by a single software load. We've been working hard to not have to localize the BIOS |
|||
user-interface by using iconic representations, both to avoid the manufacturing headaches and because the machines are often being used by kids/parents not yet literate. |
|||
Keyboard types, however, are very important to know (and while are usually related to language, they aren't necessarily a one-to-one mapping). There are actually 2 pieces to |
|||
this: the physical layout of the keys (physical size and position of keyboards), of which there will be relatively few variations (but there will be some variation), and how the keys are labeled (a silkscreening like process). There will be many, many of those. |
|||
But you want to have both pieces of information. |
|||
Revision as of 01:00, 15 September 2006
- Mitch Bradley approves with the qualification: All items marked TBD must be resolved.
- Ivan approves, same qualification as above.
- Ray <approval needed>
- Ron <approval needed>
- Richard <approves>
- Jim <approval needed> comments:
Add to goals: flexibility; there will be many keyboard variants, possibly a number of other variants of the base machine, with time.
I think either only text should be allowed, or if non-text values are essential and allowed, a type field should be added to the tags.
Should text be UTF-8, rather than ascii?
The wireless mac number: I presume this is the only location for the MAC address: there is no mac address in the wireless logic itself? I don't believe in dupicating information that may become inconsistent. What is the format of this string? (presuming it is a string).
I'm not sure language is appropriate in the area at all. What is this going to be used for?
The software load has a default locale already, and multiple languages may be supported by a single software load. We've been working hard to not have to localize the BIOS user-interface by using iconic representations, both to avoid the manufacturing headaches and because the machines are often being used by kids/parents not yet literate.
Keyboard types, however, are very important to know (and while are usually related to language, they aren't necessarily a one-to-one mapping). There are actually 2 pieces to this: the physical layout of the keys (physical size and position of keyboards), of which there will be relatively few variations (but there will be some variation), and how the keys are labeled (a silkscreening like process). There will be many, many of those. But you want to have both pieces of information.